Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
You'll need to USE this custom hook anyway inside your component, isn't it?
Those are two different things, you can simplify as much as you can the functions, apply SOLID into them and extract functions from components, but a component itself will probably need any hook (being custom or not) and some presentation logic.
It's common to use this pattern in Next JS, specially when you use SSR to avoid client-server missalignments:
if(!someProp)returnnull;
While it's not so common in React, is also perfectly valid as defensive programming technique when a prop is required for a component to render properly.
It's placed at the beginning of the component, pretty understandable and suits any case in which a default prop value is not beneficial or, if you've preference for other patterns, we can say it's beneficial whenever a ternary would be worse.
Using this pattern (or similar ones) we receive undefined as return value whenever Test component either doesn't receive a prop or the prop evaluates to falsy.
So if you do something like:
/**
* Returns a message depending on the quest result
* @param {boolean} winner
*/functionQuestResult({winner}){returnwinner&&(<p>You{winner?'WIN':'LOSE'}!</p>);
}
You'll get no message if you lose because winner is false, so it can cause non desired side effects.
So it's better to stablish that pattern as default one (from my experience):
/**
* Returns a message depending on the quest result
* @param {boolean} winner
*/functionQuestResult({winner}){if(typeofwinner!=='boolean')returnnull;return<p>You{winner?'WIN':'LOSE'}!</p>;
}
Of course you can do the same condition with a ternary:
/**
* Returns a message depending on the quest result
* @param {boolean} winner
*/functionQuestResult({winner}){returntypeofwinner!=='boolean'?<p>You{winner?'WIN':'LOSE'}!</p> : null;
}
but some components grow inevitably so they will become less readable plus this way you can control the condition easily and not having it coupled to the main return of the component. Easier to spot in PRs also!
Just look at this super simple example, we get a nested ternary here.
Is it worthy to decouple the message on a function getResultMessage(winner) or is better to use the other pattern?
And we even considered the hooks in the example above.
You'll need to USE this custom hook anyway inside your component, isn't it?
Those are two different things, you can simplify as much as you can the functions, apply SOLID into them and extract functions from components, but a component itself will probably need any hook (being custom or not) and some presentation logic.
It's common to use this pattern in Next JS, specially when you use SSR to avoid client-server missalignments:
While it's not so common in React, is also perfectly valid as defensive programming technique when a prop is required for a component to render properly.
It's placed at the beginning of the component, pretty understandable and suits any case in which a default prop value is not beneficial or, if you've preference for other patterns, we can say it's beneficial whenever a ternary would be worse.
Also consider that:
Using this pattern (or similar ones) we receive
undefined
as return value whenever Test component either doesn't receive a prop or the prop evaluates to falsy.So if you do something like:
You'll get no message if you lose because
winner
is false, so it can cause non desired side effects.So it's better to stablish that pattern as default one (from my experience):
Of course you can do the same condition with a ternary:
but some components grow inevitably so they will become less readable plus this way you can control the condition easily and not having it coupled to the main return of the component. Easier to spot in PRs also!
Just look at this super simple example, we get a nested ternary here.
Is it worthy to decouple the message on a function
getResultMessage(winner)
or is better to use the other pattern?And we even considered the hooks in the example above.
In this case nothing will be executed if props is not set (or falsy)
In this one they will be (What a waste, huh?)