Nested Update/Effects about hyperapp HOT 18 CLOSED

Vuex (Vue.js equivalent to msg) also uses a flat structure. The reasoning is, as far as I understand it, that there is no practical benefit to namespacing/nesting over simply prefixing as a strategy to avoid naming collisions.

That said, I also am curious about strategies (in general -- not just for the reducers/effects) for structuring and sensibly managing larger scale, complex apps (with potentially hundreds of reducers). All my experience with really big and complex apps is from the world of MVC, and in coming to this brave new world of the Elm-ish/React-ish paradigm, I have mostly been exposed to trivial examples and haven't found much in terms of composing larger apps from smaller pieces (like a SAM equivalent of H(ierarchical)MVC for example).

from hyperapp.

const red = require("./red-effects")
const blue = require("./blue-effects")
const yellow = require("./yellow-effects")

app({
  update: { red, blue, yellow }
})

Now there is no naming conflict but it is no longer flat 🤔

from hyperapp.

@selfup This is possible though:

app({
	update: {
		...red,
		...blue,
		...yellow
	}
})

from hyperapp.

@jbucaran it makes, but there may be name collisions... That's the important thing.

from hyperapp.

choo solved this with namespaces IIRC.

I didn't like the idea of namespaces, so I didn't implement any.

What other options do we have?

from hyperapp.

@tunnckoCore We can talk about combining this with the solution for multiple models/components/etc. though.

from hyperapp.

Forgot to close here. This has been implemented by @dodekeract and it's available from 0.6.0 🎉!

Now, reducers and effects, can be used as usual or instead of a single object with functions, can also have arbitrarily nested objects with more functions. These functions can be on the same level as the namespace or above, or under. It's recursive in nature, so you can go crazy with this.

The object that holds all this data,actions is initialized only once, so there is no fear of this slowing us down, in fact, after this HyperApp became faster. From 1.40 down to 1.37.

See #75.

/cc @nichoth

from hyperapp.

@dodekeract Interesting. Nope. I never considered this.

Sometimes because it's nice to have doesn't mean we should have it, but I am open to feedback.

from hyperapp.

Don't see value. It is better to be flat. But any use case, more real examples?

from hyperapp.

@tunnckoCore basically anything with lots of updates/effects. That way it'd be possible to split it into multiple files. It's also less tedious to prevent name clashes and easier to remember the names.

from hyperapp.

@dodekeract

const red = require("./red-effects")
const blue = require("./blue-effects")
const yellow = require("./yellow-effects")

app({
  update: Object.assign({}, red, blue, yellow)
})

Does that make sense?

from hyperapp.

choo solved this with namespaces IIRC.

Yes and no. Not exactly, or at least I think that they have the same problem in that case. There namespaces are for different models. Here we talk for one model.

from hyperapp.

@zaceno same here :) I was MVC a long ago, but still can get the Components thing really enough. But also don't have enough time and wish to review some big project using vue, react or whatever.

As about ELM-sh.. I really feel it easy and like it. Thanks to choo for very good README and intro to all that.

from hyperapp.

@dodekeract Ohh that is nice too

But then i wonder what happens if the same keys are present...which one does it call?

from hyperapp.

@selfup the last one. In this case the one from yellow.

from hyperapp.

Oh interesting! Good to know there is a fallback

from hyperapp.

Closing as I don't think I'll be implementing nested actions.

from hyperapp.

I ended up using the same nested interface in my project also to compose components, seems pretty good so far.

from hyperapp.