3 ms·

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

by iddan 4y ago

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

Huh1337 4y ago
Elm was inspired by Flux/Redux, not the other way around.
- iddan 4y ago
  Sorry no, the redux docs specifically mention Elm as an inspiration and previous art https://redux.js.org/understanding/history-and-design/prior-art https://redux.js.org/understanding/history-and-design/prior-... Flux was before, but it’s not about application as a function
  - Huh1337 4y ago
    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 4y ago
  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.
the_gipsy 4y ago
"in context", what does this mean?
- woojoo666 4y ago
  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/ https://getbootstrap.com/docs/5.0/components/accordion/
  - anacrolix 4y ago
    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 4y ago
      > 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
kodroid 4y ago
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.

by iddan 4y ago

Huh1337 4y ago

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

iddan 4y ago
Sorry no, the redux docs specifically mention Elm as an inspiration and previous art https://redux.js.org/understanding/history-and-design/prior-art https://redux.js.org/understanding/history-and-design/prior-... Flux was before, but it’s not about application as a function
- Huh1337 4y ago
  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 4y ago
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.

the_gipsy 4y ago

"in context", what does this mean?

woojoo666 4y ago
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/ https://getbootstrap.com/docs/5.0/components/accordion/
- anacrolix 4y ago
  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 4y ago
    > 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

kodroid 4y ago

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.