"Building complexity by combining things and getting the same kind of thing
that can then be used to combine with other things. "

This only works if you have an abstraction that you can't "look into". It's
actually not the case for most UI libraries that they are composable in
this way. Generally the "view" class is useless in itself and you have to
down cast to actually do anything (to a label to change the text for
example).

This is relevant to storing state because if views were a monoid (ie,
composable without abstraction leaks) then the state would be invisible to
the business logic and so could be managed internally and no one would
care. The issue is that sometimes, the business logic might care about that
state, maybe for serialisation and session save/restore.

One solution is to make the views mutable and downcast everywhere. The
other is to maintain the abstraction and so make the views immutable and
keep the state somewhere else. It's just a trade-off. I don't think you
should need to see exact examples of times it has been a problem to
understand that it will always become a problem if you add state
indiscriminately.

Theorem: The more independent stores of state you have, the faster the
difference between representable state and valid state increases.

Say you have 2 views with internal state stores A, B that have two 8 bit
integers as state. You now have 2^16 representable states (all combinations
of A and B). Maybe you know that B will only be used if A is 0, so in your
business logic you only use 2^9 states, that's 2^7 states that are
representable but invalid. (The math may be off, but I hope you get the
point.)

Now you add another view with more state C. This one is only used if both A
and B are 0. The difference between representable state and valid state may
increase exponentially, causing more chance that your total state will slip
into the invalid space due to a bug that the compiler can't help with.

So the argument that you should only have a single source of state where
all representable states are valid, and the views should be a total
function of that state seems to be the better from a risk minimisation
point of view, and really the only answer if your goal is bug free code.

I think it's still an open question as to how to do this in a performant
way and have the flexibility of a component/object model but Evan et al
seem to be making great strides.

Sorry if I went off topic. Typed this on the bus.

On Tue, 20 Sep 2016, 07:27 Peter Damoc, <pda...@gmail.com> wrote:

> Evan points out that people would consider thinking in terms of Objects
> for certain parts of the UI as a bad idea
> https://youtu.be/LCNs92YQjhw?t=1340
>
> he also points that Components are more or less the same thing and that we
> should move away from thinking about them.
>
> The  way I view it, the core idea behind Components is the closure
> property that professor Abelson speaks about here:
> https://youtu.be/2QgZVYI3tDs?t=2194
>
> Building complexity by combining things and getting the same kind of thing
> that can then be used to combine with other things.
>
> The sidebar would be a *thing, a widget, an object, a component. * Now I
> could implement it right now by using the components of elm-html and have
> that component be a simple function where some elm-html widgets are
> combined in a certain way.
>
> The problem is that *some of the components* that are needed in a modern
> UI need small state. If these components are implemented in C++ and wrapped
> by the virtual-dom, we are lucky, we can use them. If they are not, we are
> out of luck. Even a humble dropdown cannot be used as pleasantly as a
> radiobox because it needs a small "isVisible" piece of state. This has
> nothing to do with the business objectives of that UI. It is just a piece
> of transitory, accidental information. The same with an accordion, a
> datepicker or a slider. These cannot be used as pleasantly as regular
> elm-html components.
>
> elm-mdl has that closure property. One could create components that
> combine and behave like elm-mdl components.
>
> And there is no official, blessed alternative that would have this
> property for components that need a little bit of state.
>
> When I first saw the Elm Architecture I thought that it will evolve into
> something like a component architecture. In my naivety I thought that we
> will get some kind of function that would take a model, update and the view
> and would output some kind of component that would be usable in place of
> any other elm-html component. And the state would be sanely managed by the
> runtime with messages and all will be well.
>
> The elm-parts part of elm-mdl kinda does what I imagine that Elm
> Architecture would evolve into. I'm not referring to the implementation
> details of elm-parts. I'm referring to the stuff like this line:
> https://github.com/debois/elm-mdl/blob/master/src/Material/Button.elm#L417
> a call that would just wire things together and give me the thing that is
> the same as the rest of the things.
>
> I think that solving the need that prompted elm-parts would basically mean
> solving the Components issue.
>
> What am I missing here? I understand that this is a complex issue but why
> is this particular *need of a nice way of combining things that have
> behavior* not being addressed?
>
> I'm seeing the word *state* thrown around a lot but seriously, has state
> been shown to be an issue in an Elm program? (I'm talking real issues with
> a SSCCE attached not hypothetical stuff). I understand how this can be a
> problem in a language with imperative execution and global state but even
> in those languages if care is taken for state to be localized, things are
> manageable.
>
> Why not have some kind of automatic state management for these widgets?
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Dylan Sale

CTO - Enabled
enabled.com.au
08 8272 6658

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to