is inu stable?

[ahdinosaur]

at the moment the README says inu is "experimental", as described by the Node Stability Index:

This feature is subject to change, and is gated by a command line flag.
It may change or be removed in future versions.

yet i'm not sure if the core API in start (or deps pull and html) will change much if at all anymore, it seems to be simple yet powerful foundation, allowing for a wide variety of patterns to be used on top (like #11). maybe we should start calling the current API "stable":

The API has proven satisfactory. Compatibility with the npm ecosystem
is a high priority, and will not be broken unless absolutely necessary.

as for new helper functions (like #11), for the moment i've been embedding them only within the ./examples. with this, we confirm that we'd only add in helper functions once they achieve the same level of stability.

[yoshuawuyts]

How I discern between stable / experimental is: "have I used this on a big project before without wanting to change the API." - if the answer is yes, then off to "stable" a project goes.

For example with choo the API is still mildly in flux; having written 5 or so demos has shown that there's better ways of doing things, so the "experimental" badge is definitely still warranted.

Hope this was helpful!

[pietgeursen]

Do it do it do it! Call it stable! (Clearly I'm not adding anything productive, just excitement)

[ahdinosaur]

@yoshuawuyts thanks, i like that distinction. :)

so far, i've written the demos and pull-stream-docs; @pietgeursen has written ssb-gathering-ui. to me the API seems legit, if anything it's missing sugar-y sweetness but not a new foundation. meow i'm starting inu-plays-roguelike, which seems like a solid example to test the API and is more fun than yet another TodoMVC.

maybe i'll wait till a few more larger projects go well before declaring 'stable'.

[ahdinosaur]

hmm, may have found a (small) breaking change i want to make. also here's a list of breaking changes that have come up, wonder what i'm missing:

possible changes for consideration

(added in v3.0.0) run all streams

run function receives streams (as returned by start) instead of actions.

this helped immensely for a multiplayer state server like inu-plays-roguelike to send models to clients. working run-all-streams branch here.

dispatch effect

should you be able to dispatch an effect directly to run instead of going through update?

i'm skeptical that it's a shortcut but don't know specific reasons why it's bad.

i notice Elm uses the same pattern as inu:

The update function now returns more than just a new model. It returns a new model and some commands you want to run. These commands are all going to produce Msg values that will get fed right back into our update function.

also it's not difficult to create a wrapper action { effect } with update (model, action) => ({ model, effect: action.effect }).

delay next actions

should actions dispatched in views or streamed from run be delayed to update until next tick?

not sure, here's a previous conversation on the subject.

[pietgeursen]

Run

Like that run can get at the model stream.
Seems weird to pass along all the streams returned by app. Effects, views and effectActionStreams really don't seem to belong there. Tension between not being able to imagine a use case that is actually good vs allowing anti patterns.

Dispatch effect

So torn on this. I've wanted this for a while.

I can imagine some compelling arguments about the ui only dispatching actions that look like UI_DID_SUBMIT and that the ui shouldn't dispatch an effect because that somehow breaks the idea of an effect vs an action. I don't know enough about Elm to know what the deeper reasoning is there.

The down side was that I was starting to feel the pain of lots of boilerplate and felt like having this would help somewhat....

[ahdinosaur]

@pietgeursen

regarding "run":

Seems weird to pass along all the streams returned by app. Effects, views and effectActionStreams really don't seem to belong there. Tension between not being able to imagine a use case that is actually good vs allowing anti patterns.

have similar feeling to you, as for example in compose.js it'd become necessary to wrap every stream rather than just actions.

where i've found all streams makes sense: rather than wrapping your app in a higher-level function to achieve monitoring, as recommended by @gcanti for tom, you could have a single run function that monitors all events happening in the app. also, these streams are read-only, so it doesn't change how new events are emitted.

regarding "dispatch effect":

The down side was that I was starting to feel the pain of lots of boilerplate and felt like having this would help somewhat....

would your boilerplate problems be solved by using an action type like below?

(for context to anyone reading, @pietgeursen and i are playing with this pattern to structure our inu apps)

const Tc = require('tcomb')
const Effect = require('./path/to/effect-type')

const Do = Tc.struct({
  effect: Effect
})

Do.prototype.update = function doUpdate (model) {
  const action = this
  return { model, effect: action.effect }
}

module.exports = Do

used like

const Do = require('./actions/do')
const FetchCat = require('./effects/fetch-cats')

function view (model, dispatch) {
  // ...
  dispatch(Do({ effect: FetchCat({ id: 1 }))
}

[ahdinosaur]

ooh found another problem while writing inu-plays-roguelike!

even if we add "run all streams" so the run function has access to the model stream, with the way things are currently done there's no way for an effect returned by app.init to get access to the initial model.

this also highlights a difference between tom and how i implemented inu, maybe i should go back to how tom does it. namely, in tom some of the streams use RxJS "shareReplay(1)", which means that when you connect to the stream you always get the last value first. we could add this functionality to the "state-like" streams (states, models, effects, views), so we wrap the respective pull-notify .listen() functions in a way that we return something like cat([pull.values([lastValue]), stream.listen()])

[ahdinosaur]

still feeling good about the current low-level api, did some experiments for a higher-level api in inux. it's possible in the future inux will be merged into inu, but that'd mean i'd also extract the current inu to a separate module like inu-engine, sooo... stable?

[yoshuawuyts]

have you used it on actual projects yet? - calling something "stable" locks stuff down pretty hard, I'd like def hold it off till I had it out in the wild for a while

[ahdinosaur]

yeah nah, been using inu as much as able but definitely not enough, am just excited. 😄 last time i thought it was good, i found some things, so on that note i might have just found a use case where Th͏e Da҉rk Pońy Lo͘r͠d HE ́C͡OM̴E̸S and we may want to delay actions til next tick to keep zalgo (in this case an infinite loop) away.