Investigate Cerebral

[gaearon]

Cerebral by @christianalfoni seems very interesting.

People say:

sticking with cerebral. Signals concept is a winner! Latest update is even more flexible.

Is there something we can bring to Redux from Cerebral?

[Agamennon]

i was looking into it, wonder if it is able to hot-reload, but the thing that made the most sense to me was that the we are definitively doing the router wrong! this video highlights the issue.

[ioss]

Is there something we can bring to Redux from Cerebral?

The UI of the Debug-Tools? j/k

I haven't checked the complete code yet, so all my impressions are from the video. Same goes for Redux, as I just started with react two days ago. (So maybe I should not answer at all? :) )

The chaining of the signalhandlers (Cerebral: ?actions?, Redux: reducers) in response to a signal (Redux: action) is maybe - haven't decided yet - nice. It provides some documentation out of the box, but is nothing that can't be done by chaining normal functions in a reducer. Also, it will only call the handlers responsible for an action and not call every reducer (that's how I understood Redux for now). Don't know if that is performance relevant.

Also signalhandlers can return values, that get merged with their args and will be passed to the next signalhandler in the chain. Something I actually don't like, as it creates a hidden contract between any two signalhandlers.

One "thing" that we could look into is how easy it is to have async handlers/reducers (well actually more like ActionCreators) in Cerebral: Just put them into Arrays inside of the chain.
In doing it that way the devtools know that it is an async handler an will store the result, so that on replay the actual function will not be called. Which on the other hand means, that the function should probably not do any state changes and only transform/enhance the signal data to be consumed by the next sync handler in the chain.

All in all, I don't see anything that can be done in Cerebral, that can not be done in Redux.

I still think - if possible at all, still wrapping my head around it - we should come up with a solution for async, that put's the function closer to the reducers (even if it is only by naming or examples) or even into them, as this seems to be - as far as I can tell from the issues here - one of the harder problems for new users of Redux?

[christianalfoni]

Hi guys, just putting in my two cents!

I am sorry to say I have not looked too much into Redux yet... very interested, but spending as much time as I can on getting Cerebral to a 1.0 version :-)

What I think users of Cerebral benefits from, as @ioss points out, is how you define "application flow". What I mean is that when you request a state change from the UI layer, or whatever, you often have many things you want to occur. An example would be:

1. Set application in loading state
2. Get something from the server
3. Set the thing from the server in your state store
4. If server request fails, set an error in state store
5. Run some calculations etc. based on the new stuff you got from the server to set as state
6. Unset application loading state

All this is described very precise with a Cerebral signal, which also the debugger benefits from. It is not clear to me how you would define this kind of flow with Redux, but as I said, I am not familiar enough with it.

@ioss I completely see your point with the "args". The reasoning behind it is that although the actions are reusable across signals, they should be able to operate on some input to the signal chain itself and some output from a previous signal. For example handling output from an async signal. That said, this merging strategy might not be the best way to go. Let me know if you have some ideas on how it could be solved differently :-)

@Agamennon The hot-loader for React, by @gaearon, is really amazing! But one thing I think we often overlook is that the really great thing about the hot-loader is not avoiding a browser refresh, it is that the components keep their state after you change your code. So, even though you have to refresh the browser, using Cerebral, your application continues in its previous state. And it does not require React to do so. I understand Redux also has a local-storage middleware? So it works there too, but hot-loading requires React. Again, live code update is awesome for sure, but live-reload with reproduced state on load gives the same thing.. its just a browser blink further away ;-)

Thanks for taking a look at Cerebral and giving the feedback. It is just as useful for me! So thanks for putting up the issue @gaearon!

[nateajohnson]

Question for "hot loading" for both frameworks: if you've navigated a few links deep into a wizard and pulled up a modal, what happens when code is changed and hot reload happens? Does the nav and modal stay where they are with state intact?

[gaearon]

@nateajohnson This is not really related either to Redux or Cerebral and depends on your hot reloading solution. React Hot Loader keeps the state of React components so yeah, as long as you're using React, UI stays during code change.

[christianalfoni]

@nateajohnson Just adding that you can keep state with normal Live-Reload too, using Cerebral (Also Redux I think?). This does not specifically require React, but you browser will blink, as it is a full refresh.

[nateajohnson]

Thanks Dan. I only replied to this thread because it was mentioned that hot reload in cerebral works with a reload. I'm just trying to understand how that can be replayed in both frameworks. I think from what you said it works ok in redux because there is no reload.

[gaearon]

I demo hot reloading with (and without) Redux in my talk: http://youtube.com/watch?v=xsSnOQynTHs
You can indeed implement “hard” reloading in Redux with something like persistState from devtools.

[nateajohnson]

Thanks @christianalfoni and @gaearon. I appreciate the prompt answers from both of you. I think I'm starting to get it. I'm going to step out and watch both projects for a bit.

[ms88privat]

For me this "controller.signal('formSubmitted', setLoading, [saveForm], unsetLoading);" and "controller.recorder.record(controller.get());" looks really great. I think it is possible with Redux too, but you don't have it out of the box?

[idream3]

@gaearon @christianalfoni Personally I have found that the conceptual model of signals (or channels, impluses...) as implemented in Cerebral is really nice to work with.

Having all UI 'inputs' simply emit a signal/impulse when some thing has 'happened' separates the UI from taking actions directly, or, just decouples it in a way that I like. Then, It is up to the 'controller' (brain) to decide what actions to actually take.

Having the ability to look at a signal and see that it describes the action flow is fantastic, especially with async flow.

Controller.signal('formSubmitted',
  setLoading,
  [saveForm, {
    resolve: [closeModal],
    reject: [setFormError]
  }],
  unsetLoading
);

I have never liked the ActionCreator concept from Flux - Why do we need to create an action? (Although I understand the technical reason).

Oh, and the Chrome dev tools debugger is so great - being able to see each executed signal with it's corresponding actions and payloads.

I urge you to have a play with it yourself. You may be interested in something like You might be interested in https://github.com/garth/ganglion-impulse as middleware, if that is possible.

I have not had any experience with Redux yet, but I having been following closely.

Thanks for all your amazing contributions :)

[gaearon]

I have not played with Cerebral yet (lol I'm also crazy busy with our 1.0 release) but it looks like Signals correspond to Actions going through Middleware very closely. The only difference so far is that Signals seem a first-class concept, and they are composable. Maybe we can add something composable like createSignal too in 2.0. I'd like to see some API proposal here from people understanding both Redux and Cerebral.

I have never liked the ActionCreator concept from Flux - Why do we need to create an action? (Although I understand the technical reason).

An action creator in Redux isn't that different from a signal. It's just that we don't ship a helper to compose action creators into some kind of a flow. In Redux, there's an additional difference: instead of operating on the model directly, the action is given to the reducer, but in the context of signal composition this doesn't make any difference.

[philholden]

I've been doing the set loading workflow like this in redux with thunk middleware:

export function fetchCampaigns(mode) {

  return (dispatch) => {
    dispatch(setLoading(true, mode));

    getCampaigns(mode)
    .then(rows => {
      dispatch(setLoading(false, mode));
      dispatch(setRows(rows));
    })
    .catch(() => {
      dispatch(setLoading(false, mode));
    });
  };
}