Evan points out that people would consider thinking in terms of Objects for
certain parts of the UI as a bad idea

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:

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:
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

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.

Reply via email to