[apply] be able to pass in custom apply function about depject HOT 8 OPEN

Just implement depject in depject, then you could plug your own apply modules in

Not sure if I'm joking or if this is actually a good idea

Goes away and implements meta-depject package

from depject.

We could have a "raw" mode or something where you just get the array of sockets, and can call them your self, but I am curious what exactly that way to call them is and how you are using it.

depject is a very fundamental part, that forms the central architecture of the application you build with it, therefor it's extremely important to fight for elegance - to do that, we need a good map of the battlefield - which is how you actually intend to use it

from depject.

@dominictarr "raw" would work, but i find the above proposal to be more elegant, since it means you could replace the string 'first' with the function require('depject/apply').first and it'd be the same.

how i intend to use it is exactly above. currently i can't depject-ify my inu/entry code used here in catstack because i need to be able to do something like the above.

the only downside i imagine so far is that you couldn't have a depject-able apply function, since you need the apply function when creating the module so can't "need" it. but i'm not sure why you'd want that behavior.

from depject.

you'd just have a function that worked like raw did, then apply another one (which probably works like first)

@ahdinosaur can you describe how your reduce and many work though?

from depject.

@dominictarr sure. they're very specific to what i'm doing:

• inu/lib/reduce: takes many (model, action) => ({ model, effect }) functions and combines them to a single function of the same signature.
• inu/lib/many: takes many (model, effect, sources) => pull.values(actions) functions and combines them to a single function of the same signature.

from depject.

@ahdinosaur I'm a little worried that is streams overkill, not everything is a stream.
other than that, is the main difference here that everything in catstack takes 3 arguments? (model, effect, sources)?

from depject.

I'm a little worried that is streams overkill, not everything is a stream.

yeah, i'm thinking about re-writing inu to use observables, but those are streams too. 😉

other than that, is the main difference here that everything in catstack takes 3 arguments? (model, effect, sources)?

no. inu is the client-side state machine for catstack, and an inu store can have a run function which takes that signature, which is the only place it happens.

from depject.

@ahdinosaur so I'm not suggesting you do this, but building this into a custom depject makes it a bit harder to see what is happening. Hypothetically, if instead you just called it with a catstack function what would that function look like?

catstack(depject.method)(model, effect)

what would catstack look like? would it just be pull-many on a depject map?

from depject.