A bit off topic, but after studying React js and loving it I also started studying Flux. I found that the intros were a bit confusing, and needed to write a "visual cheatsheet" for my team (if interested you can find it here: http://danmaz74.me/2015/07/27/flux-architecture-visual-cheat... )
TL;DR for the React/Flux team if you read this: please update the Todo tutorial!
I agree. I've been using react with reflux, reflux is an excellent implementation of the flux model. It makes it simple to wire global modals into actions which can trigger those from anywhere in the app.
Also more on topic, I really like the material-ui project, and it's modals are quite nice.
Reflux is good, but I'm worried about how much they depart from the Flux architecture. What will happen if in the near future Facebook will release their own library? A lot of refactoring...
The action creators where a real pain point for me.
I'm coming from MVC where actions are the methods of controllers. But in Flux they are objects passed to the dispatcher and the functions who create them aren't actions, but actions creators.
But I have to say, I got my first impression of React/Flux from a project that was already using it (Redux) in production with a big chunk of integration code around it.
I initially found them a pain point because they weren't explained well - and because the name is pretty bad IMHO - but after all they're pretty simple.
I'm surprised at how many of these use props- or even methods- to show/hide the overlay rather than simply not rendering the <Overlay> component.
This article is really shallow so I'd just like to suggest you look at the code for the Rackt modal- it takes the children you pass it and renders them in a new React container, a pattern it calls a "portal". That sidesteps all of the issues with rendering a modal in the middle of your markup (CSS cascading mainly). I thought that was really clever when I saw it.
My first thought was: why are you helping people build the one of the worst UI components out there?
Not sure where it should fit in the current UI? Oh just throw it in a modal, restricting the user's ability to interact with anything else on the page, requiring an extra click to close the modal.
I'm sure there are good times to use them, but typically I find they are restrictive.
See [1] and [2] for an assessment of when (not) to use them.
They are particularly ineffective for protecting the user against errors, except on systems which use them very sparingly (such as in the web, thanks to browsers adopting non-modal bars for most warnings and search actions.) We older netizens remember the nightmare that was every other web page throwing a modal alert(); that blocked the browser on all the open tabs.)
Modals have always had a place on native apps, and they similarly have a place in web apps. If you're working on something in a single page app, you shouldn't be taken away from it just to open some settings.
It is extremely rare that you actually need to block the UI. Most uses of modals would be better served with local notification that respects fitt's law. An example would be popping up a "confirmation tooltip" adjacent to a delete button that was just pressed. The subsequent required mouse movement will be a short travel away. A modal in the middle of the screen moves the locus of focus, is jarring and blocks the UI.
Why would you not use it? You can annoy your user with it and not have the concern of being blocked by some stupid popup blocker? Do you want to take a survey? Sign up for my newsletter? I know it's your first time on the site and you didn't even get to the content yet but SERIOUSLY I NEED YOUR EMAIL ADDRESS.
Initially we used a 3rd party component but we finally wrote this much simpler version. It uses only React state variables to show/hide the modal and does not require any jQuery or Bootstrap JS to work (both of which can cause problems when mixing them with React). Feel free to reuse this code, the whole repository (Gitboard) is currently licensed under AGPL but we would be happy to provide e.g. an MIT license for the components or even make it public domain (as this is hardly more than a code snippet).
Gitboard as a whole uses jQuery, but not the component. I will have to clean up the code a bit it seems, will do that in the coming days and publish the component.
Slightly off topic, but is there an AngularJS equivalent of Elemental UI? I also find myself using the same CSS and libraries over and over again, and effectively spending too much time tweaking basic forms etc.
I feel the opposite - I don't understand why a modal should have a route most of the time. It seems clunky and usually should not be a part of browser history.
The problem I still have with the modals is the scrolling behavior. Aside from taking over the scroll event, which I do Not want to do, it seems if I want a modal to scroll without the background scrolling, the only way is to put a 'overflow: hidden' on the body tag. Anybody have a more clever way of doing this?
For one thing it hides the scrollbar which in some browsers causes the whole page to shift by a number of pixels. It's not the worst thing but it's a little bit distracting. My QA people recently sent me a bug that was basically this issue.
TL;DR for the React/Flux team if you read this: please update the Todo tutorial!