I discovered it as a problem with a third party controls children where it crashed on undefined controls. I’ve changed the hidden child controls to render as null to fix the code.
I'd argue that ternary is worse than conditional rendering. Maybe not in this the very example you're showing as it's one thing OR another, but in most cases if you just want render a single component conditionally then use... conditional rendering. It's not that hard not to assume the response of an API call and make sure to get a boolean anyway.
using && is worse then ternary for rendering, for cases when you have an if else its for obvious reasons, but when you render a single component you suddenly switching syntax? if you can keep you syntax consistent, do it, its gonna be more readable that way. and I mean, with && your basically saying "I want to render the result of X AND Component", which works how you intend it too cause JS is weird but you realize how your statement is not what you actually wanna do right? meanwhile with ternary what your saying is "if X I want to render Component, else I want to render nothing" which is exactly what your trying to achieve I know I wouldn't pass a cr if I saw someone using && for rendering as in my eyes, its less readable and shows a misunderstanding of what the language is doing, and we shouldn't base our code on misunderstandings of the language if we can help it
I think the point he’s making is that this way of using conditional rendering can potentially render something that is not guaranteed to be a Boolean. Those solutions are definitely great for type safety when you own the full stack, but what if you don’t own the server you are making calls to?
I disagree with the conditional rendering part - Using && is cleaner and easier. If the coder is using something other than a boolean, that's a bad coder that's not doing things the right way. The way we code shouldn't change because some devs don't know what a boolean is. 😛
This is the correct answer, the only time something ‘unexpected’ happens is when the value ‘unexpectedly’ doesn’t act like a Boolean like the dev was hoping.
I use lots of non-booleans in conditional rendering, but I always wrap them in `Boolean(data) && ( )`. It's the same as a double negation (!!data) but I find it more readable despite being a little longer. I dislike mixing lots of syntax symbols because a minor change in those symbols can have a big difference in the outcome, hence I prefer the very explicit Boolean() cast. However, lately I've taken inspiration from Solid and been using a ` ` component, since I find that to the most readable of all.
For autocomplete, throttling makes way more sense than debouncing, and you can make the case for having a combination of both debouncing and throttling. When it comes to conditional rendering, you're just completely wrong, each way has its use case, and developers should know the pitfalls of something before using it.
This x2 I did an autocomplete yesterday and I used throttling during writing, and debouncing to make sure that after user stopped typing the last search value is fetched
Like others have said, the first example is not necessarily the best solution. The only issue is if the value being evaluated is a boolean. In your own example, you cast one of the values as a Boolean !showValue (or whatever it was). You could do the same thing above !!showValue
that's introducing unnecessary extra processing though, sure its not much but this things add up so why not just not add them in the first place if you can help it? casting tends to be an expensive action (though admittedly I'm not sure how expensive it is in JS, didn't check)
@@נדבאהרון-ז3ח I'm not sure off the top of my head either, but I'd wager it is less than a tertiary which has to evaluate if the value is truthy or not any way
I mean, just like the tertiary the !!cast also has to evaluate if the value is truthy or not, hell they probebly use the same function behind the scenes to do this, its just thatbwith !! It has to call it twice while with tertiary it has to call it once, so theres that. In short, even though the savings in performance are admittedly, negliegble in most cases, if i had to put money on which is faster id go with tertiary The again there might be some kind of optimization baked into the language that somehow makes !! faster
If you actually have an if+else condition in rendering, going for ternary operators (?:) is also my preferred way, but if your else is just "render nothing", so "condition ? something : null", going for "condition && something" is totally fine and also my preferred way. If your condition can be a falsy value that gets rendered by react (e.g. 0), just put a !! in front of it so parse it boolean. It's not a bad thing to do so. If you are scared of bugs changing your condition's type, this is not the right spot to fix it. You should generally always parse incoming data from a third party (an api, user input, etc.). You could use libs like Zod for that. But taking that as a reason to not use && or || operators is a weird way to think imo
If you're reading this pause at 4:20 and look at the code, avoid redundant if statements, render the null being passed in the first ternary operator should be replaced with the render in the second ternary operator and completely remove the second ternary operator you don't need a redundant if statement like that.
I recently made another alternative to debouncing issue. It's technique to determine if user has copy and pasted value or actually typing value by calculating change of input text length. If user is typing user has explicitly need to click a button but if user has pasted value it will automatically trigger search function.
I'm curious. Why not just double-negate your condition? Should be much easier to parse through your code. Ternary condition kinda looks awkward in JSX. Please correct me if I'm wrong.
Imo its much better to avoid if statements overal in jsx and simply make an early return statement. If you end up with double jsx code, then it means that you havent properly split your components
casting solves the problem if the type is number or unary of number and other types. Using TypeScript you can choose to cast only when the type can be number so that is the ultimate solution
I'd prefer doing !!showWinning && ( ) or TS, I don't like that much ternary operator with large blocks, it's difficult to read. We can algo extract the blocks to variables and then use the ternary op.
Regarding conditional rendering, I feel better readability is achieved by placing the relevant HTML into a separate component and giving it a "visible" attribute. That will remove ANY related JavaScript from within the calling JSX/HTML.
I also much prefer the && condition over a ternary when you don't have a fallback. Just make sure to cast to a boolean first. If I see && I know I am conditionally rendering something. If I see a ternary I know I am conditionally rendering and I should expect a fallback template after. Not just null.
Thanks a lot. I thinking about conditional rendering: IMHO the best is create function, like renderSomethink, and inside this function return some part of jsx in conditional case const renderSomethink = () => { if (flag) { return (aaa) } return bbb }; return ( {renderSomethink()} ) ternary operators (?:) in jsx template it is terrible practice
For the first one - why not just say showWinning = Boolean(someVar) it will be safe enought to conditionally render. Better than writing ? : and nulls in my oppinion.
For deboucing we could also use useDeferredValue. This will ensure high performance for larger data const [value, setValue] = useState(""); const [data, setData] = useState([]); const deferredData = useDeferredValue(data); useEffect(() => { const id = setTimeout(() => fetch("/data").then(setData), 300); return () => clearTimeout(id) }, [value]) return ( setValue(e.target.value)} />
Instead of {x ? a : null}{!x ? b : null} you can write {x ? a : b}. Instead of ref={ref} value={value} onChange={onChange} you can write {...{ ref, value, onChange }}. Just thought you might find that helpful.
One blogger stated that using ternary operators is bad practice, while another recommended that conditional rendering should return false instead of null. It's great that I can merge both recommendations. However, it's unfortunate that the React documentation doesn't provide a comments answer on such small but useful tips.
Denounce is good, but for truly senior devs, you simply cache every idempotent iteration of whatever request makes sense to cache... if not almost all... So, just stop using lo-dash, have some balls and venture into cache re-validation, you will be really happy about all the errors you will introduce, get fired and find a better job as a consequence. Thank me later. (LOL)
it would work, but you're describing a very non-standard user interaction and is guaranteed to confuse the user. If you're considering it on the blur event, might as well just put a button next to the input to perform the search. At least then the user will know they have to do something other than type to get the result.
using onBlur makes it not autocomplete anymore, user should always see results for what he currently has typed in the input. Throttling and debouncing is to reduce server fetches to the absolute minimum while still providing satisfying user experience.
Your debounce does not solve another issue with async on user input. You set the state on resolve and don't check if the resolve is relevant to the user input. The order the asyncs are resolved are not guaranteed to be in the order the user input triggered them, debounce mediate that somewhat but doesn't eliminate it. I am not allowed to post the link to the code but if you are interested I can give it a try (yt keeps just nuking the comment if I try posting my github account or gist).
Knowing / allowing `showWinning` to be anything but a boolean IS the bug. Not the fact that 0 renders `0`. Using a ternary just adds boilerplate code and isn't any clearer in my opinion. It's a little bit like writing: ``` function isEven(value) { if (value % 2 === 0) { return true; } else { return false; } } ``` rather than: ``` const isEven = (value) => value % 2 === 0 ``` in my opinion.
In React 18 they introduced useDeferredValue hook, you could use that instead of custom solution (which is absolutelly fine looking) if you already using newest version of React
isn't just using foo && bar just fine, as even the mozilla docs says it's to check if it can be converted to false, and that it's a perfectly fine way to check if your variable or function even exists at call time
I got the general concept of a debounce but found the code a little confusing - I'll figure it out i guess. And thanks for the forwardRef overview, I haven't had to use this yet but it will be handy to know when I eventually need it.
Two different use cases. X ?? Y translates to “return Y if X is null/undefined, otherwise return X” while X && Y translates to “return Y if X is truthy, otherwise return X.” He wants to return certain JSX only if the defined condition is truthy, basically meaning it has a value, but truthy does not just mean boolean “true.” This is the issue he speaks to in his first point, since everything that isn’t falsy is considered as truthy including non-zero numbers, non-empty strings, and “true” just to name a few. His solution works, but is much more easily solved by ensuring that your condition only returns a boolean, therefore limiting your truthiness scope to one possible value of “true” and preventing other non-boolean truthy values from showing instead. All in all, nullish coalescing (??) is more specific than logical AND (&&) since it’s only checking for null/undefined, but it is more commonly compared to logical OR (||) since it’s closer in functionality.
Some great tips here! been a react dev for about a year now and I feel comfortable enough with the framework for sure, but you made me rethink again what I know best-practice-wise, and THANKS YOU for that!!
Totally disagree. It really depends on the situation and what you want to check for. If you don't need to check for the 'else' condition, using tenary operator to have a null as the 'else' is just writing extra boilerplate code for the sake of writing it. In those situations it's better to just use &&
You even showed the solution to the one very rare case when condition && something fails that being a !! operator, why make the code less readable by an ugly ternary expression?
So for the first you can and should simply use typescript and another thing you shouldn't use data from api to create the coditioning you can do .length or some other teste and the result of the test you use as the codition together with typescript it can't go wrong :D. For the second i wonder isn't const controller = new AbortController(); better than bouncing ? i'm not a programmer yet only working with react at less than 1 year but i been doing fetch requests with const controller = new AbortController(); and const signal = controller.signal;. And the third tecnacly nobody will actualy do that mistake because the app wont work
I would just make the first thign more specific and compare with actual false or undefined or whatever instead of only putting the variable. That would also work completly fine. Note: The only mistake here is using js and not typescript that would make this arguments also very obosolete.
I tend to distrust videos with titles like "don't do this" or "stop doing this". They often present personal and opinionated arguments, leading viewers to believe they're on a completely wrong path.
Cause their not neccessery? Also wont really fit with how react works... , i mean switch case could mabey work and be usefull, but if else is pointless We dont render a template like in say angular or view, instead jsx just compiles into a lot of calls to React.createComponent, in which case something like an if tag is not needed, and having an else tag come after it wouldnt really work as components cant affect their siblings
@@DJenriqez i mean sure but then again if my understanding of how react works is correct then implementing an if else tag is gonna be a fucking nightmare (also the last thing react needs is more unneeded layers to its component tree) Though i guess you could set it so that the if else tag compiles differently then all other tags to make it work, mind you just an if tag will be extremly easy, same for a singular tag that handles both the if and the else clauses, its a seperate if and else tags that work as siblings that are the problem
I totaly don't understand what you are talking about what complexity, when preprocessor see tags, he will just replace them for ? : simillar for switch, where is problem? whole react thing is fcking preprocessor which translate to document.createElement("div") , I dont see problem to implement: "when you see translate it to ? : "
Conditional rendering works fine (per CoderOne) if you actually get a boolean. So the true issue is type checking and type safety, which you get automatically with TypeScript and .tsx files instead of .jsx files. This is poor advice, ignoring a glaring problem (not using TypeScript) in favor of focusing on an easily resolved glitch that would never escape dev testing.
I love how a lot of devs tends to search for convoluted solutions to problems TypeScript already solved years ago just for the novelty of not using it and look like a pro
Why did you do: showWinning ? this : null and !showWinning ? that : null, you should have done showWinning ? this : that. Conditional rendering one element with && is fine but ternary for if else is more appropriate (or use if/else if you want to be more verbose).
next time, read the documentation instead of teaching something that you don't understand. there is nothing wrong about using "&&" operator to render something. just the very old versions of React API needed to return null
Tbh. I only watched for the first one. As it was a click bait. I agree that you should not use conditional rendering if you don't know what you are doing.. but other than that. And if you are really scared that you dont know what here is. you can use !! to convert it to boolean value
honestly, your problem with conditional rendering made me cringe so hard. Francisco Barros replied in a comment earlier !!x && component, if in doubt double bang and you are sweet. Unreal how you are peddling this tripe to juniors.
You would expect the condition to actually return Boolean, so ternary operator is much less bug resilient. Just because in your case it shows what you want doesn’t mean it’s better. Btw ternary is to render one or the other thing, so why you made two conditions there? 😂 that looks so junior.
also stop doing: 1. useEffect cancer where logic is hidden in a chain of unreadable useEffect that could totally being done in a single async function 2. application logic scatter around in the entire hierarchy of component instead of being centralize at the root of the feature
I disagree with conditional rendering part. The argument that one might have a bug in the boolean variable is not really strong argument against not using conditional rendering. IMO: ternary is ugly and I don't use it at all. Absolutely stop doing ??? This is not serious man :) However debouncing and forwardRef were good refreshers. Thanks!
yeah. the actual problem isn’t the notation. It’s non-experienced coders that write no tests and walk into wonderland. 🎉 won’t continue after first one, obviously targets non-programmers
for conditional rendering you could also just use `showWinning=== true && ()` or with a javascript typecheck `typeof showWinning === "boolean" && ()` ...
The first one is incorrect… conditional rendering is not problematic in good code.
Oh it can be if you use a numeric value, it'll attempt to illegally render the number 0 for instance. You can of course use a double bang.
He could’ve used the Boolean(showWinning) function object instead, much cleaner and easier to understand.
I discovered it as a problem with a third party controls children where it crashed on undefined controls. I’ve changed the hidden child controls to render as null to fix the code.
I'd argue that ternary is worse than conditional rendering. Maybe not in this the very example you're showing as it's one thing OR another, but in most cases if you just want render a single component conditionally then use... conditional rendering.
It's not that hard not to assume the response of an API call and make sure to get a boolean anyway.
I was a bit annoyed him calling it a MISTAKE, it's kinda clickbaity tbh
@@daliovic24 I was gonna say the same thing and you two save e the time. thanks
😂 agreed
using && is worse then ternary for rendering, for cases when you have an if else its for obvious reasons, but when you render a single component you suddenly switching syntax? if you can keep you syntax consistent, do it, its gonna be more readable that way.
and I mean, with && your basically saying "I want to render the result of X AND Component", which works how you intend it too cause JS is weird but you realize how your statement is not what you actually wanna do right? meanwhile with ternary what your saying is "if X I want to render Component, else I want to render nothing" which is exactly what your trying to achieve
I know I wouldn't pass a cr if I saw someone using && for rendering as in my eyes, its less readable and shows a misunderstanding of what the language is doing, and we shouldn't base our code on misunderstandings of the language if we can help it
@@נדבאהרון-ז3ח you use another syntax because you're not doing the same damn thing.
That's why some of us strictly use TypeScript.
Yep
Doesn’t TS only check at compile time? If you fetch data from an API, TS cant know the data was a wrong type
@@johndoe-eu4ol There is GraphQL to share the type signature with the client. Going one step further there is tRPC for end to end type safety.
I think the point he’s making is that this way of using conditional rendering can potentially render something that is not guaranteed to be a Boolean.
Those solutions are definitely great for type safety when you own the full stack, but what if you don’t own the server you are making calls to?
Exactly. Use TypeScript. The bugs the creator describes are bugs due to not using a type system. Which is a big no no for logic.
I disagree with the conditional rendering part - Using && is cleaner and easier. If the coder is using something other than a boolean, that's a bad coder that's not doing things the right way. The way we code shouldn't change because some devs don't know what a boolean is. 😛
Right . I agree
That's true, with ternary u can't use wrappers.
@@RaZziaN1 elaborate please
Also with typescript (which you should be using) it's a lot easier to ensure that your booleans are actually booleans.
This is the correct answer, the only time something ‘unexpected’ happens is when the value ‘unexpectedly’ doesn’t act like a Boolean like the dev was hoping.
I use lots of non-booleans in conditional rendering, but I always wrap them in `Boolean(data) && ( )`. It's the same as a double negation (!!data) but I find it more readable despite being a little longer. I dislike mixing lots of syntax symbols because a minor change in those symbols can have a big difference in the outcome, hence I prefer the very explicit Boolean() cast.
However, lately I've taken inspiration from Solid and been using a ` ` component, since I find that to the most readable of all.
umm yea that could be another way but that implies having tons of components
1. Use TS + tRPC to ensure you have type safety.
2. Use AbortSignal to invalidate previous requests when a new character is input. Much simpler.
I haven't seen an abort controller in a long time. Think people just don't know that something like that is a thing.
@@Voldrog yeah, I wonder why this isn't a more widespread knowledge.
Abort signal is a good decision but it doesn't reduce amount of api requests
2. It sends the same amount of requests, basically after every single keystroke. Doesn't solve the problem.
Exactly. And for the first one I will add also to use triple equality. eg: showWinning === true
For autocomplete, throttling makes way more sense than debouncing, and you can make the case for having a combination of both debouncing and throttling. When it comes to conditional rendering, you're just completely wrong, each way has its use case, and developers should know the pitfalls of something before using it.
this
This x2
I did an autocomplete yesterday and I used throttling during writing, and debouncing to make sure that after user stopped typing the last search value is fetched
4:16 sorry sir, I can't agree this approach is more readable. Less prone to errors - sure, but more readable - not at all.
The && for conditional rendering is in most cases the better solution, because a ternary operator returning null is unnecessary code
Like others have said, the first example is not necessarily the best solution. The only issue is if the value being evaluated is a boolean. In your own example, you cast one of the values as a Boolean !showValue (or whatever it was). You could do the same thing above !!showValue
that's introducing unnecessary extra processing though, sure its not much but this things add up so why not just not add them in the first place if you can help it? casting tends to be an expensive action (though admittedly I'm not sure how expensive it is in JS, didn't check)
@@נדבאהרון-ז3ח I'm not sure off the top of my head either, but I'd wager it is less than a tertiary which has to evaluate if the value is truthy or not any way
I mean, just like the tertiary the !!cast also has to evaluate if the value is truthy or not, hell they probebly use the same function behind the scenes to do this, its just thatbwith !! It has to call it twice while with tertiary it has to call it once, so theres that.
In short, even though the savings in performance are admittedly, negliegble in most cases, if i had to put money on which is faster id go with tertiary
The again there might be some kind of optimization baked into the language that somehow makes !! faster
If you actually have an if+else condition in rendering, going for ternary operators (?:) is also my preferred way, but if your else is just "render nothing", so "condition ? something : null", going for "condition && something" is totally fine and also my preferred way.
If your condition can be a falsy value that gets rendered by react (e.g. 0), just put a !! in front of it so parse it boolean. It's not a bad thing to do so.
If you are scared of bugs changing your condition's type, this is not the right spot to fix it. You should generally always parse incoming data from a third party (an api, user input, etc.). You could use libs like Zod for that.
But taking that as a reason to not use && or || operators is a weird way to think imo
If you're reading this pause at 4:20 and look at the code, avoid redundant if statements, render the null being passed in the first ternary operator should be replaced with the render in the second ternary operator and completely remove the second ternary operator you don't need a redundant if statement like that.
I recently made another alternative to debouncing issue. It's technique to determine if user has copy and pasted value or actually typing value by calculating change of input text length. If user is typing user has explicitly need to click a button but if user has pasted value it will automatically trigger search function.
03:37 Debouncing
09:56 Forward Refs
I'm curious. Why not just double-negate your condition? Should be much easier to parse through your code. Ternary condition kinda looks awkward in JSX.
Please correct me if I'm wrong.
One quick question: What is the vsc theme?
Imo its much better to avoid if statements overal in jsx and simply make an early return statement. If you end up with double jsx code, then it means that you havent properly split your components
Related to first mistake
Is better to convert inputvalue to boolean by !!
or is it still not good solution?
casting solves the problem if the type is number or unary of number and other types. Using TypeScript you can choose to cast only when the type can be number so that is the ultimate solution
@@und0 Of course, but the variable is showWinning. Based on name it should be boolean adn it should be defined as boolean
I'd prefer doing !!showWinning && ( ) or TS, I don't like that much ternary operator with large blocks, it's difficult to read. We can algo extract the blocks to variables and then use the ternary op.
That's why everyone uses typescript. Boolean && is just fine, keep using it
Regarding conditional rendering, I feel better readability is achieved by placing the relevant HTML into a separate component and giving it a "visible" attribute. That will remove ANY related JavaScript from within the calling JSX/HTML.
I also much prefer the && condition over a ternary when you don't have a fallback. Just make sure to cast to a boolean first. If I see && I know I am conditionally rendering something. If I see a ternary I know I am conditionally rendering and I should expect a fallback template after. Not just null.
Thanks a lot. I thinking about conditional rendering: IMHO the best is create function, like renderSomethink, and inside this function return some part of jsx in conditional case
const renderSomethink = () => {
if (flag) {
return (aaa)
}
return bbb
};
return (
{renderSomethink()}
)
ternary operators (?:) in jsx template it is terrible practice
For the first one - why not just say showWinning = Boolean(someVar) it will be safe enought to conditionally render. Better than writing ? : and nulls in my oppinion.
or use !! for converting to boolean
Typescript identifies the boolean problem and makes surprises much less likely.
Does any problem to use let instead of const in component or define props or arrow functions
For deboucing we could also use useDeferredValue. This will ensure high performance for larger data
const [value, setValue] = useState("");
const [data, setData] = useState([]);
const deferredData = useDeferredValue(data);
useEffect(() => {
const id = setTimeout(() => fetch("/data").then(setData), 300);
return () => clearTimeout(id)
}, [value])
return (
setValue(e.target.value)} />
);
Experimental
@@victormog No, it's not. It's stable since React 18.
@@grenadier4702 Ok!
Instead of {x ? a : null}{!x ? b : null} you can write {x ? a : b}. Instead of ref={ref} value={value} onChange={onChange} you can write {...{ ref, value, onChange }}. Just thought you might find that helpful.
what is vscode theme?
Great video! Which theme do you use in VSC?
I would like to know either
Halcyon ^_^
@@CoderOne Thanks! Keep going with this type of content
One blogger stated that using ternary operators is bad practice, while another recommended that conditional rendering should return false instead of null. It's great that I can merge both recommendations.
However, it's unfortunate that the React documentation doesn't provide a comments answer on such small but useful tips.
Blogger 😂
It seems that use useRef for debounceValue instead of useState in useDebounce is much better, because it reduces the times of re-render
Denounce is good, but for truly senior devs, you simply cache every idempotent iteration of whatever request makes sense to cache... if not almost all... So, just stop using lo-dash, have some balls and venture into cache re-validation, you will be really happy about all the errors you will introduce, get fired and find a better job as a consequence. Thank me later. (LOL)
7:14 , can we use onBlur instead of onChage , hence when focus is lost from input, the fetching happen , rather than each key press
it would work, but you're describing a very non-standard user interaction and is guaranteed to confuse the user. If you're considering it on the blur event, might as well just put a button next to the input to perform the search. At least then the user will know they have to do something other than type to get the result.
using onBlur makes it not autocomplete anymore, user should always see results for what he currently has typed in the input. Throttling and debouncing is to reduce server fetches to the absolute minimum while still providing satisfying user experience.
what is your vscode theme?
Your debounce does not solve another issue with async on user input. You set the state on resolve and don't check if the resolve is relevant to the user input. The order the asyncs are resolved are not guaranteed to be in the order the user input triggered them, debounce mediate that somewhat but doesn't eliminate it. I am not allowed to post the link to the code but if you are interested I can give it a try (yt keeps just nuking the comment if I try posting my github account or gist).
May i know the theme name?
I never had this problem cause when i started react, i also started using typescript
Knowing / allowing `showWinning` to be anything but a boolean IS the bug. Not the fact that 0 renders `0`.
Using a ternary just adds boilerplate code and isn't any clearer in my opinion.
It's a little bit like writing:
```
function isEven(value) {
if (value % 2 === 0) {
return true;
} else {
return false;
}
}
```
rather than:
```
const isEven = (value) => value % 2 === 0
```
in my opinion.
Hey can you tell me which file icon you were using?
3:50 put the bottom return as the false expression for the first ternary
does React Query handle the debouncing for you?
In React 18 they introduced useDeferredValue hook, you could use that instead of custom solution (which is absolutelly fine looking) if you already using newest version of React
please share the official documentation on that hook, or you mean a custom hook....
No they didn't, wtf?! I think you mean useDeferredValue which is similar but the same
@@und0 yes I meant exactly useDeferredValue 😅 I will fix it in my commit, sorry
isn't just using foo && bar just fine, as even the mozilla docs says it's to check if it can be converted to false, and that it's a perfectly fine way to check if your variable or function even exists at call time
I got the general concept of a debounce but found the code a little confusing - I'll figure it out i guess. And thanks for the forwardRef overview, I haven't had to use this yet but it will be handy to know when I eventually need it.
Second problem - why not write usual debounce function except this hook??
Why are we all using && and not ?? (null coalescing)?
Two different use cases.
X ?? Y translates to “return Y if X is null/undefined, otherwise return X” while X && Y translates to “return Y if X is truthy, otherwise return X.”
He wants to return certain JSX only if the defined condition is truthy, basically meaning it has a value, but truthy does not just mean boolean “true.” This is the issue he speaks to in his first point, since everything that isn’t falsy is considered as truthy including non-zero numbers, non-empty strings, and “true” just to name a few.
His solution works, but is much more easily solved by ensuring that your condition only returns a boolean, therefore limiting your truthiness scope to one possible value of “true” and preventing other non-boolean truthy values from showing instead.
All in all, nullish coalescing (??) is more specific than logical AND (&&) since it’s only checking for null/undefined, but it is more commonly compared to logical OR (||) since it’s closer in functionality.
Some great tips here! been a react dev for about a year now and I feel comfortable enough with the framework for sure, but you made me rethink again what I know best-practice-wise, and THANKS YOU for that!!
Totally disagree. It really depends on the situation and what you want to check for. If you don't need to check for the 'else' condition, using tenary operator to have a null as the 'else' is just writing extra boilerplate code for the sake of writing it.
In those situations it's better to just use &&
Debounce good thinking this could really smooth things for my app project. PS: Really like the duality when sharing good code to better coding.
TS solves the issue of the conditional variable being a non boolean type. Use TS. It's 2022, everyone should be using TS.
hey man, I finally understand how forwardRef works!
You even showed the solution to the one very rare case when condition && something fails that being a !! operator, why make the code less readable by an ugly ternary expression?
So for the first you can and should simply use typescript and another thing you shouldn't use data from api to create the coditioning you can do .length or some other teste and the result of the test you use as the codition together with typescript it can't go wrong :D.
For the second i wonder isn't const controller = new AbortController(); better than bouncing ? i'm not a programmer yet only working with react at less than 1 year but i been doing fetch requests with const controller = new AbortController(); and const signal = controller.signal;.
And the third tecnacly nobody will actualy do that mistake because the app wont work
I would just make the first thign more specific and compare with actual false or undefined or whatever instead of only putting the variable. That would also work completly fine.
Note: The only mistake here is using js and not typescript that would make this arguments also very obosolete.
Why not use double ! to cast as a boolean? It's cleaner than a ternary.
why can't we prepare a value first and the apply a conditional rendering (for example with !! or Boolean())
double negation (wich always results in an actual boolean) is way quicker and safer than a ternary :
!!showWinning && ...
I tend to distrust videos with titles like "don't do this" or "stop doing this". They often present personal and opinionated arguments, leading viewers to believe they're on a completely wrong path.
Need more of this!
Thanks for the forward ref explanation
react developers changed react routing milion times but no way they will add and tags....
or at least a keyword prop "if"
Cause their not neccessery? Also wont really fit with how react works... , i mean switch case could mabey work and be usefull, but if else is pointless
We dont render a template like in say angular or view, instead jsx just compiles into a lot of calls to React.createComponent, in which case something like an if tag is not needed, and having an else tag come after it wouldnt really work as components cant affect their siblings
a lot of things is not neccessery but its nice to have,... like ? : and && looks inside react component just terrible
@@DJenriqez i mean sure but then again if my understanding of how react works is correct then implementing an if else tag is gonna be a fucking nightmare (also the last thing react needs is more unneeded layers to its component tree)
Though i guess you could set it so that the if else tag compiles differently then all other tags to make it work, mind you just an if tag will be extremly easy, same for a singular tag that handles both the if and the else clauses, its a seperate if and else tags that work as siblings that are the problem
I totaly don't understand what you are talking about what complexity, when preprocessor see tags, he will just replace them for ? : simillar for switch, where is problem? whole react thing is fcking preprocessor which translate to document.createElement("div") , I dont see problem to implement: "when you see translate it to ? : "
You just use '!!' To force null force coalescence.!!! For false.
Conditional rendering works fine (per CoderOne) if you actually get a boolean. So the true issue is type checking and type safety, which you get automatically with TypeScript and .tsx files instead of .jsx files. This is poor advice, ignoring a glaring problem (not using TypeScript) in favor of focusing on an easily resolved glitch that would never escape dev testing.
First problem - just use TS!
dubouncing starts at 4:45 not 3:37
wtf?
Debouncing 8:05
Nice
I love how a lot of devs tends to search for convoluted solutions to problems TypeScript already solved years ago just for the novelty of not using it and look like a pro
Boolean(showWinning) &&
He already did that using !! before the condition....
!!showWinning &&
why not just use the useeffect and grab the data once on mount
2:10 "We all know 0 actually is the same as false" Wow...
It is not the same, what you have probably wanted to say is that is is **falsy**.
Why did you do: showWinning ? this : null and !showWinning ? that : null, you should have done showWinning ? this : that. Conditional rendering one element with && is fine but ternary for if else is more appropriate (or use if/else if you want to be more verbose).
That is why we should use TypeScript
Typescript saves !
Great explanation. Thank u
next time, read the documentation instead of teaching something that you don't understand. there is nothing wrong about using "&&" operator to render something. just the very old versions of React API needed to return null
Another piece of information Thank you so much.
Tbh. I only watched for the first one. As it was a click bait. I agree that you should not use conditional rendering if you don't know what you are doing.. but other than that. And if you are really scared that you dont know what here is. you can use !! to convert it to boolean value
I use !! to avoid 0 😂
honestly, your problem with conditional rendering made me cringe so hard. Francisco Barros replied in a comment earlier !!x && component, if in doubt double bang and you are sweet. Unreal how you are peddling this tripe to juniors.
Why not (showWinning === true) && ?
Thank you... for qaulity content... debounce trick seems to be smooth.
wao, you vs**e looks like my neovim code editor, cool
Just use double bang (`!!`) or `{Boolean(data) && }`. Not that difficult
You would expect the condition to actually return Boolean, so ternary operator is much less bug resilient. Just because in your case it shows what you want doesn’t mean it’s better. Btw ternary is to render one or the other thing, so why you made two conditions there? 😂 that looks so junior.
Vs code theme?
also stop doing:
1. useEffect cancer where logic is hidden in a chain of unreadable useEffect that could totally being done in a single async function
2. application logic scatter around in the entire hierarchy of component instead of being centralize at the root of the feature
Amazing tips! Subscribed!
LOL why null after : just use the loser fragment
Like ?
I disagree with conditional rendering part. The argument that one might have a bug in the boolean variable is not really strong argument against not using conditional rendering. IMO: ternary is ugly and I don't use it at all.
Absolutely stop doing ??? This is not serious man :)
However debouncing and forwardRef were good refreshers. Thanks!
yeah. the actual problem isn’t the notation. It’s non-experienced coders that write no tests and walk into wonderland. 🎉 won’t continue after first one, obviously targets non-programmers
Thank you so much!
I just watch a video that said && is better ...
That's why we have TypeScript.
&& with array is 0 when length is 0
abort api calls for me at least seems better than debounce.
Lol. If you end up receiving a 0 number from the BE, when you expect a boolean, how is that a React FE issue
interesting, thank you
for conditional rendering you could also just use `showWinning=== true && ()` or with a javascript typecheck `typeof showWinning === "boolean" && ()` ...
U mad