Register/Login

[NilsG-S]

To Do:

• Fix tests
• Does name need an explanation (e.g. non-identifying)?
• Change over to new password rules
• Have errors show up in banner (redux + single banner?)
• Have explanations show up in Tips (redux + single Tip?)

Done:

• Implement server API
• Change over to new schema

[NilsG-S]

@asclines Would it be a good idea to move the password checking functions to common so we can keep them consistent?

[asclines]

What password checking are you referencing? If you are talking about the ones we use in user models, I would go ahead and say no as that uses bcrypt I believe and some other things that shouldn't be in the front end code.

[NilsG-S]

Ah, I guess I misspoke. I meant the input validation.

[ynigoreyes]

Using material snackbars (notifications on the bottom that popup) would be the way to go for global error handling. I just don't know if we should use redux to handle that. It's more of an event, than it is a state problem. I feel like it would just crowd up our store since we would need a ERROR_RECIEVED and ERROR_HANDLED action.

global eventListener?

[NilsG-S]

I think a global EventListener would be the same as simply having a new Snackbar element for each Snackbar source. Material-UI only allows a single existing Snackbar at a given time. So it works fine, but you run into situations where one is overwritten by another before its timeout. Which, while not ideal, is also not a huge deal.

Let me know if I've misunderstood what you meant by a global EventListener.

If we want to ensure each Snackbar gets its time in the spotlight, we could put a queue in Redux. Then we could have a component that pops everything off the queue into its internal state. But that doesn't sound like MVP.

[ynigoreyes]

I think I should be more clear about what I had in mind.

Forms would have their own errors for each input. Like if a user's password was not strong enough, you would see that message as a input hint in red bellow the input.

However, network errors should be global. If there is ever a global error, I would like to just emit an event which will propagate a Snackbar to show. With each Snackbar only lasting 2-3 seconds, the overlapping Snackbars should never really happen.

[NilsG-S]

That makes sense. I have an instinctual dislike for using events to accomplish something we could do with Redux. Global EventListeners are basically magic. One component dispatches an event into the ether and subscribers are notified. With Redux we can keep an accounting of what information is being distributed throughout the app. If we bypass that single source of information, we could end up with consequences that are hard to track down. That said, doing so in this one case probably won't be too terrible.

How much of an issue is store crowding? From a code perspective, it's relatively easy to separate reducers into multiple files. Does a large store become performance limiting?