Often times React components become hard to understand due to conditional rendering. Β At first a simple if/else or ternary operator appears benign ...
For further actions, you may consider blocking this person and/or reporting abuse
This looks really nasty. It's always better to such keep logic out of jsx. We have a switch operator for that.
I see what you are saying; you could very well use a switch operator as well. The concept here was to demonstrate how you can wrap
RenderIf
to create a richer API for your JSX.What I'm saying is that RenderIf is a huge mess and should not be used
I've used it on several projects where teams were really happy with it. I'm curious why you think it is a "huge" mess considering the alternatives and potential pitfalls?
Cool idea. I think components like your
RenderIf
can help convey what you are doing. At least in complex scenarios, they can be easier to reason about than complex statements. Thus, gathering experience as to when to do this kind of refactoring is important, but a nice inspiration.There are also babel JSX extensions that allow conditional rendering like the following ones
npmjs.com/package/babel-plugin-jsx...
npmjs.com/package/babel-plugin-jsx...
That is really nice! I think the one caveat here is that it is harder to discern the code paths in your components since the condition is nested in your component vs physically part of your component tree. I find it easier to see using
RenderIf
or something similar which also makes it easier for me to see the various conditions I need to test.100% agreed, but thatβs still an option
I like the idea of pushing your conditions down your React tree wherever possible, so like passing
isUnicorn
down into the Login component and handling that condition internally.That works too. But then you are mixing presentation logic in with your component code vs having only what you need in your component. I think having your presentation logic outside of the component makes things easier to reason about and make sure that components aren't doing more than they should.
Not sure I agree, the whole point of props is to change what's rendered, from the user's perspective the difference is probably "the login is themed differently when I'm a unicorn", so what's the meaningful difference between, swapping a whole component in this level, doing the swap inside or changing styles internally, so why does it matter that it's handled outside the component or in it? It sounds to me like exactly part of the component's responsibility.
Also, turning JSX into a logic heavy DSL is not my jam at all.
That is true. But, something still needs to conditionally render based on those prop changes. I've outlined many ways to do that in this post and suggested a way that I prefer using
RenderIf
. If it is not your thang, that's cool. Readability is subjective to some degree. I personally find it easier to take in JSX that looks more like HTML than a mix of HTML and JS if/else/switch statements.For sure, which is why most of the time I prefer calculating as much as possible in plain JS so the JSX is mostly just JSX, even if it's just putting the ternaries into constants
Totally. You can clean up a ton of JSX by extracting variables and doing calculations prior to rendering. That is a great point and I find myself doing those refactors when I'm trying to make components more readable.
XState and React Query I think helps a lot with this overhead. I loved the explanations super detailed and learned a lot about cyclomatic complexity.
Amen
What about this.?
const RenderData = ({ data }) => (!!data.length) && data.map(...);
That would return
false
. I think the trap here is that it is easy to forget to cast thedata.length
to a boolean type.