Just give it some clear names and you're ok, instead of users.name.type === "Owner" && you can create a const with a name const isOwner = users.name.type === "Owner" and then do isOwner && .
It seems no mayter how many PRs we send back with that exact note, the same thing keeps happening. I had one yesterday with 5 checks, with some being nested.
I'd say the example you linked down in the comments is definitely not optimal. Instead of using ternaries and especially nested ternaries (avoid like plague imo), a better practice is to separate your rather gigantic JSX the function returns into many smaller components, and inside the components you can do conditional returns, like so:
You definitely will create so much code that it will become worst in terms of readability if it's a complex case of conditional rendering and it will require a lot of prop drilling. That is why I love the Python Zen because it shows how readability comes not only from making things easy to read, but also compact without hurting the readability that you want to achieve. You definitely shouldn't have to use nested ternaries, but definitely ternaries and || + && have as many use cases to improve readability as ifs.
I don't think it is a bad thing if all of them are necessary. Btw i would like to take a look at ur project if you would allow, i would like to learn together with you. Cheers😊
Been having the same issue recently. Does anyone have an example showing other solutions achieving the same way instead of conditional rendering on a component?
If it gets too many, it's probably time to consider putting them in its own component to handle the logic so it doesn't flood existing code with ternary conditions, especially when they're in the middle of your JSX. Six is a lot, 3 is my limit.
It's okay to have many condition in one jsx render but they need to be readable easily. What I mean by that is the condition itself, understanding there is a switch and on what. This means that you should avoid having too much tags and extract blocks into their own components or variables. As other people already said here, a react app is literally a chain of conditional rendering. It's a matter of making it readable. This advice is not specific to jsx anyway.
Well, you should consider to do some refactoring to your component, for example by delegating some decisions to the parent component calling the one you are asking for
The longer I write React, the more I try to avoid conditionals ANYWHERE in the code, but especially in jsx. 6 conditionals on your jsx means you need to write at least 12 tests of that component.
Only thing I'd say is that rather than putting all that JSX in one massive return statement, it is often more readable to have multiple clearly named components (functions) being conditionally rendered, even if you put them all in the same file.
You can also return JSX from local functions. Consider stuffing common elements into these and then use multiple return statements from your react component.
I think as a general rule conditionals should be kept to a minimum where possible. You're much better having a single conditional render 2 different components at the top rather than have conditionals littered through a single component, even if fundamentally they're quite similar. DRY is great, except when it isn't. Duplicate code is more extendable as it's independent of other changes.
SPAs are just a long series of conditional renders.
Isn’t life just a bunch of conditional renders?
Nice quote
TechnicallyTheTruth
"SPA is just conditional renders with extra steps"
Just give it some clear names and you're ok, instead of users.name.type === "Owner" &&
It seems no mayter how many PRs we send back with that exact note, the same thing keeps happening. I had one yesterday with 5 checks, with some being nested.
If functionality/desing states requires it. Sure.
Big plus on the isolated functions. Seeing people chaining ternary operators quickly becomes very hard to read
I'd say the example you linked down in the comments is definitely not optimal. Instead of using ternaries and especially nested ternaries (avoid like plague imo), a better practice is to separate your rather gigantic JSX the function returns into many smaller components, and inside the components you can do conditional returns, like so:
You definitely will create so much code that it will become worst in terms of readability if it's a complex case of conditional rendering and it will require a lot of prop drilling. That is why I love the Python Zen because it shows how readability comes not only from making things easy to read, but also compact without hurting the readability that you want to achieve. You definitely shouldn't have to use nested ternaries, but definitely ternaries and || + && have as many use cases to improve readability as ifs.
It doesn't have to matter. If you use hooks from Redux Toolkit to determine what to show:
Really has nothing to do with rtk this stuff exists in pretty much all react applications
I don't think it is a bad thing if all of them are necessary. Btw i would like to take a look at ur project if you would allow, i would like to learn together with you. Cheers😊
https://github.com/dragoslavIvkovic/Test-your-JS-skills---NEXT.JS-REDUX-MONGODB/blob/main/pages/QApage.js
Been having the same issue recently. Does anyone have an example showing other solutions achieving the same way instead of conditional rendering on a component?
Are you using Routes?
If it gets too many, it's probably time to consider putting them in its own component to handle the logic so it doesn't flood existing code with ternary conditions, especially when they're in the middle of your JSX. Six is a lot, 3 is my limit.
It's okay to have many condition in one jsx render but they need to be readable easily. What I mean by that is the condition itself, understanding there is a switch and on what. This means that you should avoid having too much tags and extract blocks into their own components or variables. As other people already said here, a react app is literally a chain of conditional rendering. It's a matter of making it readable. This advice is not specific to jsx anyway.
It's fine if it meets your needs. Could be messy though, especially if deeply nested. I would consider nested components at that point.
I used to used Conditional Renders instead of React Router to handle different pages lol
Well, you should consider to do some refactoring to your component, for example by delegating some decisions to the parent component calling the one you are asking for
If u want to make code more readable try "react-if" package.
I prefer to avoid packages
The longer I write React, the more I try to avoid conditionals ANYWHERE in the code, but especially in jsx. 6 conditionals on your jsx means you need to write at least 12 tests of that component.
A single component with a lot of conditionals isn’t bad. Conditionals every where tends to mean the design is bad.
This file
I wouldn’t, personally I would split it into smaller components if possible and then conditionally render the components instead of the JSX
This would be cleaner but essentially the same performance, right?
Only thing I'd say is that rather than putting all that JSX in one massive return statement, it is often more readable to have multiple clearly named components (functions) being conditionally rendered, even if you put them all in the same file.
You can also return JSX from local functions. Consider stuffing common elements into these and then use multiple return statements from your react component.
[удалено]
It is not bad, but I would say the conditionals should be on the same "level".
I think as a general rule conditionals should be kept to a minimum where possible. You're much better having a single conditional render 2 different components at the top rather than have conditionals littered through a single component, even if fundamentally they're quite similar. DRY is great, except when it isn't. Duplicate code is more extendable as it's independent of other changes.
That's like saying that code with if statements is an anti-pattern
No effect on performance but you might want to consider refactoring your logic and separating those conditionals to separate smaller components
in short and easy: put the conditions outside of the return and store them in their own variable. eg: