Best way to implement modals and notifications in React Flux
Asked Answered
K

2

14

Modals and Notifications are components that are appended to the body. So they work little different than normal components. In my App, I can think of two ways of implementing them and I am not sure which one is better.

  1. No stores

In this approach, I create a NotificationHelper class which has a create method. Inside that, I create a new container node, append it to the body and then call React.render(, container);

So any component can call NotificationHelper.create() and it will create a notification. Notification component that manages it's lifecycle and closes when the timer expires or somebody clicks on the close button.

The problem is often times, I need to show notification on the page in response to XHR response (success or failure), so in my actionCreator, I will have code like this

APIManager.post(url, postData).then(function(response) {
    NotificationHelper.create(<SuccessNotification />)
});

I don't know if it's correct to call something like this from action creator that renders a new component.

  1. With stores

Another approach is to create a NotificationStore and on emitChange render the notification component. The code will look something like this

In my App.js, the code will be

<body> 
    <Header />
    <Fooder />
   <NotificationContainer />
</body>

And then in NotificationContainer, I will do something like

onChange: function() {
    this.setState({customNotification: NotificationStore.get()});
},
render: function() {
    <Notification>
        {this.state.customNotification}
    </Notification>
}

And finally, the action creator will look something like

Dispatcher.dispatch({
   actionType: 'notification',
   component:  <MyComponent/>
});

The problem with this approach is the additional overhead of stores. Store is not doing any meaningful thing here, it's only there just to follow the flux. From action creator, we are passing data to the store, and the component is again taking the same data from the store and rendering it. So we finish the flux cycle without really getting anything out of it.

Also, I now need to initialize NotificationContainer at the start of my app, even though I don't have any notifications at this point.

Kilimanjaro answered 17/12, 2014 at 19:10 Comment(0)
R
1

I don't really see how your problems are problems. It does exactly what it's supposed to do, and if you need to build on it later, you can easily do so. Notifications and other no-true-component-owner features are one of the best reasons to use flux in my opinion (90% of the time I don't recommend flux).

With flux the notification action creator would be responsible for creating a remove notification action after a set period of time. You can also have an x button on the notification, which when clicked creates that action, and these go to the store which removes the item if it exists, and any/all views dependant on this store update. When I say any/all I mean that the notifications component may be hidden, or there may be an alternate way to view notifications on one page of the app, or there may be a simple counter with the number of notifications anywhere in the app.

Side note: don't pass around elements in a way that they could be rendered more than once. Pass {component: SuccessNotification, props: props} instead if you need to specify the component ahead of time.

Ryan answered 18/12, 2014 at 2:39 Comment(0)
D
0

I follow the answer of FakeRainBrigand.

Sorry the self promotion here but I created a Notification component that you can use with Flux. Here you can see a issue that shows a example of usage with Alt, but the principles are the same. You add the component to a top level element on your HTML and subscribe that component to a Notification store. On your notification action creator, you can add notification with some properties like: level, position, auto-dismissible, action, etc.

Here is the component demo.

Damask answered 14/9, 2015 at 15:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.