The length of the render function makes it difficult to know what all it's responsible for.
I broke out the wrapper <div>
into a small component, and the AgGrid row into a separate component.
I don't know how Flux works, but I'd make each of the user controls their own components. They can update the store as they do now (roughly, depending on how Flux does things like this) with results/etc still handled by the containing component.
I flattened this out to avoid deep nesting, which makes things difficult to think about. Since none of the conditions depend on each other, and everything is short, this was easy, and early returns are easy to reason about.
I moved the FeedbackMessage
processing into a switch
statement. This is a stylistic choice, but IMO they're easier to update when you add additional feedback messages. This should be moved into a separate function, though, which makes testing even easier.
If I were doing this in real life I'd probably still whittle this down to a set of states encompassing the feedback messages, data errors, and success. I'd move it either into a switch statement, or a map of states => methods, or whatever.