A pattern I have used sometimes is to have the context passed as a list
instead of a record:
type Options = OptA | OptB Float | OptC Color
-- A call with default options:
view [] model
-- A call with custom options:
view [OptA, OptC red] model
Actually, now that I think of it, that is how eve
I'm building quite a large app at present and find myself passing more and
more into the view functions in addition to that component's model. I feel
reassured knowing that the view function can't mess with any state and the
diffing engine is ensuring that I'm not causing more DOM work than
nec
I think the first solution (context/options argument) is the clearest and
simplest. Yes, it's a bit verbose, but:
- You can use the 'view' and 'viewWithOptions' pattern where the former
calls the latter with a default primary color etc., so you can get
convenience if you don't care abo
I *think* I am trying to solve a conceptually similar issue in my elm-irc
library.
The library exposes a bunch of typical irc/chat commands, such as "send
message", "join chatroom" and so on. All these commands need some common
configuration (mainly the IRC server address). I find it overly com
