In React Redux the View Tree knows no details of the separate Singleton App
State Tree Object & its Business Logic (aka Store). The View dispatches an
Action (JS Obj {type:SOME_ACTION_TYPE, payload:{...} to the Store, which
Functionally Updates & notifies any views interested in these State Model
changes. Sorry if this murky, for which UNIDIRECTIONAL USER INTERFACE
ARCHITECTURES by Andre Staltz
<http://staltz.com/unidirectional-user-interface-architectures.html> explains
this better & compares other approaches. If you interested in learning
basic principles of React Redux, Dan Abramov's free Eggehead course is
excellent Getting Started with Redux
<https://egghead.io/courses/getting-started-with-redux>
On Tuesday, April 5, 2016 at 10:10:05 AM UTC-7, John Orford wrote:
>
> +1 for the topic guys
>
> this question was my first cause of cognitive dissonance I had since doing
> Elm arch apps up...
>
> dare I say it, but out of curiosity, how do react / redux ppl handle this?
>
> On Tue, 5 Apr 2016 at 14:06 Simone Vittori <[email protected]
> <javascript:>> wrote:
>
>> I've been tinkering around with this pattern for a while now and I can
>> say it worked pretty well for me. I haven't built anything exceptionally
>> complicated here, but I managed to make a small demo of the credit card
>> form you were talking about.
>>
>> Here's a live demo <http://www.simonewebdesign.it/demo/elm/> + code
>> <https://github.com/simonewebdesign/elm-double-folding-pattern/blob/master/Main.elm>.
>>
>> The pattern is pretty much like you described it, except it doesn't have a
>> *handleEvent* function (I think it's simpler to directly fire Actions
>> and Events, at least up to a certain extent); also Model and ViewState go
>> straight to the view.
>>
>> One thing that's immediately noticeable is that I haven't used StartApp,
>> because I didn't really feel the need for it, but I don't see why not.
>> However I'd be more inclined to go towards a modified version of StartApp
>> that already has the concept of Actions + Events.
>>
>>
>> On Friday, 8 January 2016 16:13:00 UTC, Max Goldstein wrote:
>>>
>>> There's been a lot of threads on the list lately about how to architect
>>> large applications. They basically boil down to two questions.
>>>
>>> - How can we separate business logic and domain data from
>>> view-specific layout and animation?
>>> - How can we write components that can be easily nested?
>>>
>>> I have an idea, but first, let's review the standard Elm Architecture
>>> (as I understand it):
>>>
>>>
>>> <https://lh3.googleusercontent.com/--hOlLN8diqY/Vo_Yvm6_6OI/AAAAAAAAAdo/1fxPd2sadaQ/s1600/elm_diagram_basic.png>
>>>
>>> A few notes on the diagram: Read clockwise. Monospaced font indicates
>>> things in Elm, with capitalization indicating type. Inputs are on the left,
>>> and outputs are on the right.
>>>
>>> One of the "smells" is that HTTP responses and clock ticks are both
>>> Actions that get handled together. The Model also must keep all information
>>> needed to render the view, so if you want to serialize the model, that's
>>> non-trivial.
>>>
>>> Let me use the specific example of a credit card order form. When the
>>> user clicks "submit", an HTTP POST request is sent, and the submit button
>>> is disabled (perhaps with a click animation). These are separate: one is a
>>> business-level action, and the other is a UI event.
>>>
>>> As another example, consider a drag-n-drop list of items. At any given
>>> moment we might be animating an item snapping into place, or moving it
>>> between lists. During this time, if you were asked to serialize the model
>>> and send it to the server, what would you do? There's no good answer.
>>> Therefore the state of where something is painted onscreen is separate from
>>> the model of the data itself.
>>>
>>> With these examples in mind, please consider this pattern:
>>>
>>>
>>> <https://lh3.googleusercontent.com/-OD_Q-fi4RU4/Vo_a_hypD6I/AAAAAAAAAd0/rgv6JjUi0BQ/s1600/elm_diagram_complex.png>
>>>
>>> This is, essentially, the folding pattern applied twice. There are two
>>> large loops: all the way around, and through Event (skipping Action and
>>> Model). The Model contains the business data, and the ViewState contains
>>> the animations, button toggled states, field data, and so on. And Event (a
>>> union type) can be a new Model, a clock tick, or something that came from
>>> HTML.
>>>
>>> HTML events don't map cleanly on to whether a business-logic Action or a
>>> view-level Event has occurred. Going back to our credit card order form,
>>> each digit entry can be an Event, but a completed card number can be an
>>> Action that gets saved in the model. Something is needed to determine
>>> whether a button click extends a panel or sends data to the server, or
>>> both, and I've called that something *handleEvent*. It's responsible
>>> for turning the low-level HTML event API into something meaningful in the
>>> application. (Alternatively, the HTML events can directly fire Actions and
>>> Events.) This sort of layer between input and application commands allows
>>> one to say, have remappable keyboard shortcuts, or have a button click and
>>> a keypress do exactly the same thing, since they send the same Event.
>>>
>>> This is still just a diagram and I haven't written any code, so I expect
>>> this to be refined through implementation and discussion. For instance, I'm
>>> not completely sure how the model should get passed around: as NewModel
>>> Model event, or perhaps render should be *render : Model -> Event ->
>>> ViewState -> ViewState*, or perhaps the model should go straight to the
>>> view. I don't think this could be codified quite like StartApp, at least
>>> not yet, it's more of a pattern than a library.
>>>
>>> I opened with two concerns, and I think this pattern solves the first
>>> one reasonably well. But I think it can also help the second one,
>>> composition. By knowing that each component has business logic in one
>>> place, and view state separately, things get easier to compose. First, the
>>> Models will probably need to be coupled from parent to child, based on what
>>> the application is, but the ViewState can be independent. When a parent
>>> receives a clock tick event, it passes it on to the child, always. (Ideally
>>> it wouldn't need to do anything, but we can work on that.) And effects can
>>> turn from "please run this opaque task" to something semantic, like "please
>>> submit this credit card data", which the parent might need to inspect.
>>>
>>> I realize this is a bit long for a post but I'm eager to hear what
>>> people have to say about this pattern.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>> 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 [email protected] <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 [email protected].
For more options, visit https://groups.google.com/d/optout.
