<div dir="ltr">Make your 'displayTable' function take a 'NonEmpty a' instead of a List (eg. [a] or Vector a). That at least ensures that you won't ever be showing an empty table. I don't think there is a Map/Set-equivalent of NonEmpty. But you will have to convert a Map/Set into a list at some point, and that's where you can again use NonEmpty.<div><br></div><div><a href="https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/base-4.9.0.0/Data-List-NonEmpty.html">https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/base-4.9.0.0/Data-List-NonEmpty.html</a><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 16, 2017 at 1:54 PM Saurabh Nanda <<a href="mailto:saurabhnanda@gmail.com">saurabhnanda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Everyone,</div><div><br></div><div>In most user-interfaces we need special-treatment for blank states (zero-item state). For example:</div><div><br></div><div>* In case there are no customers, don't show an empty table, instead show the message "You seem to have no customers, why not start by creating one..."</div><div>* In case there are no bookings, don't show an empty table, instead show the message, "No bookings here. Want to create one?"</div><div>* In case there are no search results, don't show an empty table, instead show the message, "No items found. Undo your last filter?"</div><div><br></div><div>In some cases, the one-item case also needs special treatment, but I'm unable to come with relatable examples at the moment.</div><div><br></div><div>A lot of times the dev simply forgets about the blank state, and it is caught during QA, which results in a quick-fix on the following lines:</div><div><br></div><div>    if length item > 0 then displayTable else showBlankState</div><div>    if Data.Map.Strict.size map > 0 then displayTable else showBlankState</div><div>    if Data.Set.Ordered.size set > 0 then displayTable else showBlankState</div><div><br></div><div>Is there a way to prevent this bug from the get-go? Can we use the type-system (or anything else) to enforce the dev to at least _think_ about the blank state? Obviously, the type system can't help us with _what_ needs to be done with the blank state, but at least it can _remind_ the dev at compile-time about handling blank states.</div><div><br></div><div>-- Saurabh.</div>
</div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>