should `combine` and `first` order be reversed? about depject HOT 7 OPEN

Hmm, it depends on how you are using reduce - I figure in reduce, the default (in core) goes first and then the customization gets called after - to wrap the default value. so using that way, we'd want the most specific to run last, and the least specific to run first. I guess we could just add reduce-right though?

however, I feel we don't really have great data on using reduce yet.

from depject.

Which was @clehner's idea. I guess it's not hard to just do it in that order, maybe we should just make the documentation clear about that.

from depject.

whatever order we choose, i think we will want reduce to match right? as in i think it would be better (haven't yet hit a real-world use case for overriding my reduce-able configuration) for reduce functions to first call core, then userland, then customizations last.

from depject.

I think the existing order is good.

I like that at the moment apply.js is just sugar over Array.prototype.find (though I see you avoid that in favor of imperative syntax, presumably to cater to older JS implementations), Array.prototype.map, Array.prototype.reduce - it would be a drastic breaking change and if you're going to do a breaking change I'd personally like to see first be renamed find rather than changing the directionality but really don't care that much.

The current order of reduce also aligns with the directionality of Object.assign

You can emulate different directionalities pretty easily already, just by reversing the input, or you can not reverse them and still emulate last by abusing reduce

from depject.

i keep running into a problem in catstack (a full-stack framework using depject) where i want the developer to be able to override any framework module, so put the user's modules first, but then that means some helper modules used to create plugs aren't available within create. i've been working around it so far, but have seriously thought about adding a "priority" to modules to determine what runs first, second, etc, but switching the order should also work for the reasons in the original post.

from depject.

I fear that priority might be necessary (other similar systems have it sometimes) but I'd sooner make a breaking change to the ordering. @ahdinosaur I think changing the ordering would give you what you are looking for. you can override modules, and you'll have the general modules initialized before the specific.

from depject.

so i forgot about this issue and implemented priority: https://github.com/depject/depject-priority. but i think i still want to reverse the order.

from depject.