I initially thought that the suggested implementation by Facebook was a bit weird because it requires a lot of boiler plate code.
For the longest time I disliked using magic strings for type checking since it breaks the concept of polymorphism. In Javascript it is even more weird considering it is a dynamic language. So I fixed that by moving the type specifics (which in Flux's case is mostly about handling events) into the actions and stores themselves.
Thanks to a contributor we also provide a mixin for React components that adds automatic unsubscription on componentWillUnmount and provides a listenTo method in the components to subscribe to actions and stores.
It works both server-side (available at npm) and client-side (available as bower package or can be built in browserify from npm package).
Thanks for posting - I'm glad to learn about reflux here. I started adding flux to an application as prescribed and thought there were many strange and unnecessary steps. All the flux libraries seemed equally complicated. Instead I went with a simple event emitter approach, which is basically Reflux without the nice API. I will certainly give it a try.
Technically passwords that should be retrieved at a later date are stored using two-way encryption. So the thing is, the passwords are always "visible", as they're retrievable. Removing the "Show" button is not really making things more secure as it is retrievable using other means. This is same with all browsers that save passwords.
You could lock it away with a one-way encrypted password but the problem with that is it's just "theatrics", giving a false sense of security... the stored passwords are still two-way encrypted either way, or else they can't be retrieved for later use. That means it is just as breakable as if they weren't. Once the hacker finds the password database on your computer it should be considered compromised.
If you don't trust your browser or your computer then you should use a service like LastPass or 1Password, i.e. if you consider them trustworthy to handle your passwords and if you're not on an insecure WIFI network. There is really no other way around it.
I do agree though that all browsers should be more clear about it... unfortunately it's not particularly easy to explain computer security to a user who is not a computer science nerd.
I initially thought that the suggested implementation by Facebook was a bit weird because it requires a lot of boiler plate code.
For the longest time I disliked using magic strings for type checking since it breaks the concept of polymorphism. In Javascript it is even more weird considering it is a dynamic language. So I fixed that by moving the type specifics (which in Flux's case is mostly about handling events) into the actions and stores themselves.
Thanks to a contributor we also provide a mixin for React components that adds automatic unsubscription on componentWillUnmount and provides a listenTo method in the components to subscribe to actions and stores.
It works both server-side (available at npm) and client-side (available as bower package or can be built in browserify from npm package).