making deeply nested update effectful requires cascading refactoring about elm-architecture-tutorial HOT 6 CLOSED

I think it depends on your context. Today, I'd probably make everything have the more general type, just in case. I think for beginners, that type is probably a bit fancy.

If you want to have "local effects" then you want a language that is not pure. I don't think there is any way to avoid propagating things around in a pure language. The only thing you can do is make it look different.

from elm-architecture-tutorial.

I think it depends on your context. Today, I'd probably make everything have the more general type, just in case. I think for beginners, that type is probably a bit fancy.

That pretty much could be a solution. It's just lot of emphasis in this brilliant tutorial is on how you can easily reuse code and grow your program without re-architecting bits built previously. I think this gives a really great learning curve.

But then if you do introduce a concept that requires changing all of those bits you did before it is definitely a significant draw back.

If you want to have "local effects" then you want a language that is not pure. I don't think there is any way to avoid propagating things around in a pure language. The only thing you can do is make it look different.

I don't consider propagating things to be in issue in this case, but rather a fact that introducing an even simple animation into code base that was following the rest of the proposed architecture in this tutorial requires a significant refactoring. To be clear it's not just impression I get, it's actually what happened in project I'm working on, we are introducing some gesture animations and doing that required change to half of the modules we've written, part of it is because ui component was deeply nested but still it was big enough change that we decide to use a different approach for this milestone and get back to this later. Solution we came to introduces fake animation event that is triggered on next animation frame, handler of that event sends AnimationFrame to make it tick. So instead of scheduling a tick from the update instead we check rendered state in the view function and either have next animation event handler or not depending if animation needs to progress. This is far from ideal but at least we could leverage existing action forwarding via addresses and avoid refactoring a lot of code that contained animated element.

To be clear this issue was exactly about the look and feel of the API not about the need of passing effects. For example addresses solve in many ways same problem and they could be completely rerouted without causing significant changes to the existing code base. I was merely interested if some alternative API could be explored that may have different draw backs :)

from elm-architecture-tutorial.

@Gozala said

For example addresses solve in many ways same problem and they could be completely rerouted without causing significant changes to the existing code base. I was merely interested if some alternative API could be explored that may have different draw backs.

I don't know for sure if it would make a difference for your situation, but if you're interested in an alternative API for effects, you could take a look at https://github.com/rgrempel/elm-architecture-tutorial and https://github.com/rgrempel/elm-ticker. They do rely on addresses and 'forwardTo' to do their effects routing, and so might be an example of an API with different draw-backs.

from elm-architecture-tutorial.

There is one more thing I considered doing that I have not tried yet. I was thinking about adding something like commit function along the side of view and update that could run after update and just return effect(s) that need to run. Again I have not tried it yet to have a real input to provide I'm afraid, but it may have a potential to resolve the refactoring problem, as introduction of effects into system will introduce new commit function you need to implement but that would not require you to change all your update functions.

from elm-architecture-tutorial.

@Gozala: I have done something similar to that with a separate reaction function, which is separately dispatched -- that is, update stays the same, but a separate reaction function computes just the effect.

I haven't broken this pattern out into a general library, but you can see an example here.

Of course, this requires wiring your signal graph in a particular manner that I have described here.

The code may not be super-easy to follow, because I've done some further work on how super-modules and sub-modules are wired together with records that isn't well documented yet. As the code settles down, I'll eventually break it out into better-digestible examples.

from elm-architecture-tutorial.

@rgrempel thanks for the pointers I'll look into those and see if I could reuse some those ideas.

I have also being thinking that actual pattern described in this tutorial could work just as fine it's just may make sense to rename update to step and let it delegate to update to compute new model and and some other function say react to compute effects to be performed then results. I'm just not sure if in practice it will turn out to be convenient, I imagine there will be some of the same kind of boilerplate for sub-module delegation for both update and a react.

from elm-architecture-tutorial.