1. 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 && .

  2. 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.

  3. Big plus on the isolated functions. Seeing people chaining ternary operators quickly becomes very hard to read

  4. 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:

  5. 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.

  6. 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😊

  7. 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?

  8. 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.

  9. 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.

  10. It's fine if it meets your needs. Could be messy though, especially if deeply nested. I would consider nested components at that point.

  11. 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

  12. 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.

  13. A single component with a lot of conditionals isn’t bad. Conditionals every where tends to mean the design is bad.

  14. I wouldn’t, personally I would split it into smaller components if possible and then conditionally render the components instead of the JSX

  15. 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.

  16. You can also return JSX from local functions. Consider stuffing common elements into these and then use multiple return statements from your react component.

  17. 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.

  18. No effect on performance but you might want to consider refactoring your logic and separating those conditionals to separate smaller components

Leave a Reply

Your email address will not be published. Required fields are marked *

News Reporter