Thanks Mark for this fantastic and very detailed answer.
I never thought about applying regression to a UI state and I definitely
want to mull about the idea further.
My gut feeling tells me that manually informing the shrinker wether it's a
good or bad state is gonna be too much work but
Oops, that second annotation should be
viewHelper : { a | name : String } -> Html Msg
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I see now. You want to see a UI widget in many possible states for the
purposes of seeing a visual regression. (By "widget", I mean some piece of
HTML generated by a function, not the loaded word "component", which
usually implies state. Although it could be either.) Without saying too
much, I
Thanks for your answer Max,
When I think about using fuzzers outside elm-test one of the use cases I
have in mind is something à la devcards https://github.com/bhauman/devcards
If you don't know about it it's a very useful tools used by the
clojurescript community to mount a UI using different
Hi Frankie, thanks for trying Elm, glad you like it!
> But why isn't the ability to create fuzzy records/data available outside
> that package? What I usually do is to stub out the UI given a certain model
> type. Being able to call fuzzy generators in my Main namespace to populate
> the
A syntax that would make sense with current trends in elm is something to
the effect of:
model
|> Record.map .val1 increase
|> Record.update .val2 42
This of course relies on `Record.map` and `Record.set` which do not exist
and (ab)uses .field syntax in ways which don't actually work.
Op maandag 5 december 2016 21:00:35 UTC+1 schreef Frankie Sardo:
>
> Why does the update syntax accept just a new value instead of accepting a
> function that updates (or creates) the new value?
>
Don't know about Clojure, but Elm likes you to be explicit and consistent
about functions,
