Peter, you may be interested in (and I'd appreciate your feedback on) a 
little library I've been working on for composable input widgets: 
https://github.com/kintail/input-widget

It seemed to me that in many cases of 'little bits of local state', the 
widget in question is an input widget of some sort like a fancy dropdown, a 
date picker, a small form with a few fields + validation etc. where it has 
some transient internal state to keep track of but all the higher-level 
code really cares about is the output value produced. As a result I created 
the input-widget package to experiment with combinators (map, map2 etc.) 
for input widgets and I think so far it's worked out pretty well; you can 
pretty easily do things like add validation or decoration to widgets, 
combine a 'first name' and a 'last name' widget to produce a 'person' 
widget, etc. You can also define custom input widgets using TEA functions 
(which can then be composed etc. just like any other input widget) or 
easily embed input widgets into a normal TEA program. Right now the only 
primitive widgets I've implemented are 'checkbox' and 'lineEdit', and 
there's no documentation yet, but you should be able to check out the 
examples directory to see how things work.

Internally this does a couple dirty-ish things (the 'State' type includes a 
bunch of functions which is generally frowned upon, and messages are all 
passed around as JSON to avoid an explosion of types) but from the outside 
it should be quite type safe (I'd love to hear about any holes people find).

Ultimately I'd like to create a parallel output-widget package for 
composable output widgets following the sortable-table example (internal 
state handled internally, current value to display passed into 'view').

On Tuesday, 20 September 2016 10:13:43 UTC+10, Nick H wrote:
>
> 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.
>
>
> Abelson is just defining and combining functions. Adjusting for syntax, 
> you could write code in Elm that looks essentially the same.
>
> (DEFINE P (BESIDE G (ROT-180 (FLIP G)) .5))
>
> What is conspicuously absent in this example is anything that looks like 
> an object or a component. All of the old state is in "G". All of the 
> behavior is in the functions. All of the new state is in "P".
>
> Abelson did not show in his slides here the code for rendering the view. 
> But this would just be a function that takes P (or G) as input. In Elm, it 
> would just return Html.
>
> This has nothing to do with the business objectives of that UI. It is just 
>> a piece of transitory, accidental information.
>>
>
> As far as the view function is concerned, there is no difference. Every 
> bit of information needed to draw the view needs to get passed to the view 
> function as an argument.
>
> That doesn't mean that all of your update functions need to operate on the 
> totality of your state (although in Abelson's example, they do!). You 
> should have separate functions to deal with updating that UI state and 
> aspects of your "business" state, and these can be delegated from your 
> overarching update function.
>
> Scheme is a nice illustration that functions are the only tool you need to 
> manage complexity. If there are pain points in scaling Elm programs, the 
> lack of components aren't the culprit.
>
>
>  
>
> On Mon, Sep 19, 2016 at 2:57 PM, Peter Damoc <pda...@gmail.com 
> <javascript:>> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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