Assigning in registered callback

[accidentallyc]

In this fluxify, you use the updater in action callbacks to mutate the store values. E.g.

actionCallbacks: {
        changeName: function( updater, name ){
            // Stores updates are only made inside store's action callbacks
            updater.set( {name: name} );
        }
    }

In facebook ( excerpt below ), you can mutate the store value in the callback.

//From https://facebook.github.io/flux/docs/dispatcher.html
flightDispatcher.register(function(payload) {
  if (payload.actionType === 'city-update') {
    CityStore.city = payload.selectedCity;
  }
});

So how do we update store values using just the store registered callback function?

[ducman]

Not exactly sure what you're asking but the actionCallbacks function in the store does the updating of the store's state/data using the updater. The dispatcher is already built into the fluxify's store so you never have to worry about it.

[accidentallyc]

Hi , sorry if i confused you.

I mean that in fluxify, is the updater the only way you mutate the data?

I wanted to use the facebook style implementation but I couldn't find a way to update the data that way.

From your docs

It is possible to use it like Facebook's dispatcher implementation, registering action callbacks and dispatching payloads.

var callbackId = dispatcher.register( function( payload ){
    if( payload.actionType = 'log' )
        console.log( 'I was logged by an action!' );
});

dispatcher.dispatch( {actionType: 'log'} ); // log 'I was logged by an action!'

[ducman]

I would say yes and no (note that the author of fluxify may say otherwise). You can use the dispatcher to dispatch, register callbacks and use it just like the fb style implementation but you'll have to create your own stores, manage the data, and emit data changes yourself. You won't be able to use fluxify's store (I don't think). So pretty much you're only using the dispatcher part of the flux architecture.

Fluxify's store has the singleton dispatcher built into it so you'll don't have to register any callbacks. It has a somewhat immutable data storage (that's why you can update only through the updater). It also has an emitter to let your react components know what data has changed. It's all built exactly using the flux architecture but with all extra coding like registering call backs, immutable data storage, async promise feature, a change emitter, etc. already done for you.

You'll have to create a store as in the example. When you handle an event in your react component, you'll dispatch the event flux.doAction('actionName', 'exta data'). In your react componentDidMount, you'll listen to your store changes myStore.on('change:name', value => this.setState({value});. In case your component get unmounted, you would unlisten with off.

I've been using it for a while now and I find it to be the most simplest flux implementation unlike others out there. I don't like writing a lot of code, especially if a lot of the code look the same and does the same thing. I tend to think of fluxify as a big shortcut.

[accidentallyc]

Ahhh, figured as much. Also i thought you were the author , my bad =D . Well i guess i could live with that. Thanks haha

[arqex]

@ducman thanks for the kind reply. Completely agree with you, fluxify just works in a different way that facebook's flux trying to make the dev create less boilerplate code, even if there is a dispatcher I strongly recommend creating the stores that automatically get register in it.

Also I've been working for a while in a tool that let you build react apps even with less boilerplate code, freezer:

https://medium.com/@arqex/react-the-simple-way-cabdf1f42f12#.icv7eumlo

That's why I am not paying fluxify all the attention that it deserves.

Since you are actively using it, would you want to be collaborator of the project??

Cheers