[iddan]

This is basically introducing Elm (a.k.a the inspiration for Redux) to Android. At least for me this model doesn’t work. Application is all about transitions of state, yes, but in context. That’s why React’s model of managing multiple state points in different levels of the application tree makes so much more sense to me

[kodroid]

Thanks for the input.

Your totally right, it's pretty similar conceptually to Elm in many ways, amazingly I only discovered Elm in the last 8 weeks or so after writing applications in this way for the last few years, maybe not surprisingly as I have been a mobile developer for 13 years and Elm is not big in the mobile space!

> Application is all about transitions of state, yes, but in context.

Like the other commentor says, it would be great to hear more about what you mean exactly by "in context" here.

[the_gipsy]

"in context", what does this mean?

[woojoo666]

Not GP but I can try to explain. React tries to be as functional as possible, but components are still often stateful. For example, an accordian component [1] could have a `collapsed` boolean state. This `collapsed` state makes sense within the context of the accordian component.

Now imagine if you tried to move the state out of all your components into a single location, so that your components can be stateless functions. Now that your variables are out of context and might collide with each other, you might need to rename this `collapsed` state into something like `landingPageItem4AccordianCollapsed`. This is why you shouldn't use global state (like Redux) for everything, and it's often best to keep state close to the UI component it belongs to. This keeps things grouped by context, and makes it easier to navigate and reason about the code.

[1]: https://getbootstrap.com/docs/5.0/components/accordion/

[anacrolix]

I don't think that's right. I think you'd have a global state like landingPage.Items[].Accordion, and the accordion code in any location would be passed its state and messages already unwrapped by the parent. Nobody would need to know about its collapsed field or any other state it tracks for that matter

[woojoo666]

> I don't think that's right. I think you'd have a global state like landingPage.Items[].Accordion

Somebody correct me if I'm wrong, but I believe this is what React is already doing under the hood when you use useState(). React probably has some big internal global state, and then maintains mappings between state and components, so that when a component is re-rendered, React can pull up the corresponding state for that component.

So even though the components are technically stateless, they can still be considered "stateful" because each component has a corresponding portion in this global state. Notice how in your landingPage.Items[].Accordion, if you change the layout of your landing page, you might now have to change the structure of your global state as well. So this is why React's syntax for keeping the state definitions inside the component is so nice. It prevents you from trying to keep the structure of your global state and the layout of your components in sync.

P.S. I like your work on torrents :P I knew I recognized that username from somewhere

[the_gipsy]

Ah, got it, thanks!

IMHO, Component style (React) and State style (Elm) can be interpreted as two styles of isolating (or decoupling), just very orthogonal to each other. Isolating is a very basic necessity for keeping complexity at bay.

Component style isolation works really well for "inner UI state", like your accordion example. But it quickly gets out of hand once you get to some non-UI state that is shared between a bigger component hierarchy.

State/View/Message isolation works really well for actually keeping the views pure and having only one change-message channel. But the state model quickly (and message handler) quickly gets huge. You also cannot publish/provide a small "component" with local state.

[Huh1337]

Elm was inspired by Flux/Redux, not the other way around.

[iddan]

Sorry no, the redux docs specifically mention Elm as an inspiration and previous art https://redux.js.org/understanding/history-and-design/prior-...

Flux was before, but it’s not about application as a function

[Huh1337]

Hmm, you're right, Redux first appeared in 2015 and Elm in 2012. I was early adopter of both (didn't stick with Elm though) but I guess I only noticed Elm once it got popular. Thanks, my mistake!

[dminuoso]

Neither is the case.

Elm semantics were originally loosely based on functional reactive programming in the sense of Conal Elliot, as per the thesis of its author.

Redux on the other hand is just imperative programming folks rediscovering that a state transition can be described as a pure function S -> S, with all the benefits that come along with it. This is as old as lambda calculus itself. Words like reducer are just red herrings.