Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Notification component implementation #123

Open
igorprado opened this issue Oct 9, 2015 · 5 comments
Open

Question: Notification component implementation #123

igorprado opened this issue Oct 9, 2015 · 5 comments

Comments

@igorprado
Copy link

Hi,

First of all, thanks for this boilerplate! It's awesome!

I've been playing with this and tried to implement a component that I created for notifications. I set this version using the component: https://isomorphic-react-app.herokuapp.com/

You can see the notifications when:

  • Delete a user
  • Add a user

When adding a user, sometimes it will fail and display a error notification and sometimes it will be success, just for simulation purpose. In case of fail, there is a button where the idea is re-do the action.

My concerns and goals here are:

As I'm new to Flux implementations, my question here is about the structure of the store and actions, if you guys think it's ok. The repo is here: https://github.com/igorprado/isomorphic-react-app

Thanks!

@igorprado igorprado changed the title Notification component implementation Question: Notification component implementation Oct 9, 2015
@cridenour
Copy link

Hey - I think this looks pretty good.

The only thing I would change is in UserActions.add(), I wouldn't pass along the structured notification object in the action unless you truly only think the NotificationStore is the only one that will ever consume the event.

If you passed just the user to UserActions.success() and maybe just the callback to UserActions.fail() and then have all the "notification logic" in the NotificationStore, that would be more in line with the Flux implementations I've seen.

@igorprado
Copy link
Author

Thanks for the reply, @cridenour.

I agree with you. Indeed we can have more stores listening to requests actions in this case. I made several changes to the first approach. One is this: firing the notification action from UserActions.addSuccess() and UserActions.addError().

One of the biggest changes was: I created a notification store/action and notifications store/action. The notification action/store is responsible for fire a single notification. The notifications action/store is responsible to hold all notifications that were successfully added/removed after validations/animations of the notification component. I couldn't figure out a better way to do this.

Some of the things that I want to achieve (and achieved, at least until now) is:

  • Ability to fire notifications from a component or other actions;
  • Ability to intercept error requests and fire a notification (API must follow a pattern of errors object so it can be consistent).

@iam4x
Copy link
Owner

iam4x commented Oct 13, 2015

@igorprado With Axios you can intercept requests, but careful since it's a singleton library on server side it won't fit great with multiple requests at same time.

I have an example of notifications into one of our product at work, I need to clean that and do a gist.

@igorprado
Copy link
Author

Thanks @iam4x, it would be great!

Indeed a singleton pattern to achieve this may be a problem. I'll search more about it.

@jaredcat
Copy link
Contributor

Thanks for bringing this to light. I didn't think/know about axios being singleton. Might also cause issues with our app.
What a good method of building a API library in this environment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants