[Haskell-cafe] Ensuring that blank-state has been handled in UIs?

[Mario Rogic]

I think you might find the RemoteData solution here relevant to your
problem:
http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

I've been using it successfully for a lot of UI work. Even if you have a
default handler function that gives a sane-ish default value for the
context you'll be using it in (I.e "Loading..." in UI), I've found it helps
keep interfaces sane even when you "forget" you actually care about the
empty state.


On Sun, 16 Apr 2017 at 15:07, MarLinn <monkleyon at gmail.com> wrote:

> On 2017-04-16 13:51, Saurabh Nanda wrote:
> > Can we use the type-system (or anything else) to enforce the dev to at
> > least _think_ about the blank state?
>
> That is an interesting problem. But I'd say the solution depends highly
> on your architecture. Tomas' suggestion to use NonEmpty could be one
> solution, and one you could try to build upon to track more details in
> the types. Alternatively, you could add a typeclass that just handles
> the zero-element-case. That way your constraints remind the developer to
> at least copy-paste a default implementation.
>
>         showItemTable :: (HasZeroItemPresentation (presenter item)) =>
> presenter item -> [item] -> Table item
>
> But maybe there's a much simpler solution: Create a datatype that stores
> the normal presentation function, a zero-case presentation function, and
> optionally a one-item presentation function. Now whenever someone
> creates a new type of item, they need a new presentation adapter.
>
>         data TablePresenter item = TablePresenter { showZeroItems ::
> Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item ->
> Widget) }
>
>         showItemTable :: TablePresenter item -> [item] -> Table item
>
> This should offer safety and code reuse, and it should be easy to
> integrate because you don't even have to start with types. Why be fancy
> when the simple solutions work?
>
> Cheers,
> MarLinn
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
- Mario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170416/90bfca30/attachment.html>