The code is cleaner when splitting it out into components, agreed; however, I don’t think it should be the job of a component to decide whether itself should be rendered or not (e.g. the Sidebar component returning null if the sidebar is not supposed to be open). I think the caller/consumer of a component should decide whether it’s to be rendered or not, and components themselves should be just that: The component markup and any features/state _within_ the component.

@tehtriangle6660

6 ай бұрын

100%. By adding in the conditional, you're now making the component consider state outside of it's immediate concern.

@permanar_

6 ай бұрын

Idk why but kinda agree with this.

@Benedictator123

6 ай бұрын

Can we have this discussed cos this feels important

@TheNeonRaven

6 ай бұрын

100% agree if you're talking about actual independent components, however this makes more sense if you're just breaking out small parts within a single file, and those "sub components" aren't externally accessible. This is pretty much refactoring out a function and failing early to make it more concise.

@fullstackjedi

6 ай бұрын

While I agree this is just contrived example.

I use ternaries a lot in Svelte property bindings. When it's a simple case, it's way easier than creating a whole function for it.

It’s crazy that it’s about to be 2024 and devs aren’t just returning null for React components.

@nicosoftnt

6 ай бұрын

It was 2024 for me when you commented this

@nathangwyn6098

6 ай бұрын

Explain? Is this a jab at react?

@semyaza555

6 ай бұрын

@@nathangwyn6098 it’s a jab at React devs.

@semyaza555

6 ай бұрын

@@nicosoftnt what time zone?

@nathangwyn6098

6 ай бұрын

@semyaza555 I don't get it though lol ita going over my head. If you just return null with all your components nothing will be rendered? X.x

The problem with breaking it out into components is that it's verbose. Most people using && use it for small pieces of content, not anything huge that makes sense to break out into its own component.

@oscarhagman8247

6 ай бұрын

well yes we mostly use && for small little things, but as he said when you start to fill up your markup with too much ternary (especially nested ones at that) then it's a good idea to break it out into a component to keep it clean. He didn't say don't use them at all, just don't overdo it

@cooltrashgamer

6 ай бұрын

Another solution with the control flow discrepancy, you can treat it more like a ternary guard clause: {!arr.length ? null : arr.map(el => {return (el % 2 === 0) ? null : {el}})} Makes it a little cleaner when your null case isn't so far away from the ?

@Svish_

6 ай бұрын

And now you have to go find those components, to figure out what happens if the state changes. For small stuff, I rather use `&&` and `? :` every time.

@mharley3791

6 ай бұрын

I think verbose and easily readable is better than terse and hard to follow

@JamesW6179

6 ай бұрын

I have slowly come to link "verbose" as a synonym for "maintainable".

I hope you discuss more technical topics like this.

I tend to overuse ternaries because I wasnt sure if creating a bunch of components with properties that drills was good practice. Thank you for sharing your opinion! I will try to change my practice and see if I find a preferred one

So Theo you're ok with returning null from a component? I've always avoided it, and prefer to not even call the component in the case it shouldn't render. Do you have any reasons to use null?

@jordan59961

6 ай бұрын

same

@victorlongon

5 ай бұрын

Keep doing that, passing a boolean to show or not the component is just dumb, imho 😊

In the first example you can just map over the array without any checks: mapping over an empty array renders nothing. No checks on contacts.length are necessary.

@mintlata

6 ай бұрын

Sometimes you would want to show something to the user that the array is empty, like a message ("You don't have any..."/"This list is empty") or an icon or something, that's where ternaries (or just a simple if-else) is good for.

@ea_naseer

6 ай бұрын

​@@mintlatacouldn't you just pass the html as a string to a variable and then after mapping check if that variable is null. If it is return your special message if not return the markup. That is verbose but much cleaner IMO

@SamuliHirvonen

6 ай бұрын

@@mintlata yeah, and often you don't want to render the surrounding wrapper at all for 0 elements, then lifting the length check higher up makes more sense than in the example.

@DaviAreias

6 ай бұрын

Just put !!contacts.length

@mintlata

6 ай бұрын

@@ea_naseer I’m not sure I understood your idea. Can you give an example?

8:40 T[0] is still different from T[number]. I know you know, but some viewers could be misled. for example for a type like this: [number, string]. Typescript knows your first element is a number, your second is a string, and it has two elements. So T[0] will be number while T[number] will be number | string.

@mart3323

6 ай бұрын

Was about to point out the same, but while double checking in ts playground i noticed the example wasn't recursive either. To unwrap arbitrarily nested arrays, it would have to be Flatten in the true branch

@andreasherd913

6 ай бұрын

well this is done with T extends (infer R)[] ? R : T, not T[0]

@Exilum

6 ай бұрын

@@andreasherd913 T[number] as in the example works just fine, I see no need to infer a second temporary type, it's just extra processing for your IDE.

@happylittlesynth

6 ай бұрын

Can someone please explain this a little further? I've re-watched this part multiple times and I still don't quite understand why you need to do this (also a typescript n00b)

@Exilum

6 ай бұрын

@@happylittlesynth Imagine types as being a special kind of value. We don't know anything about T at first. When you do T extends any[], you are checking if T is included in the definition of any[], meaning, T must be an array. We still don't know what T contains. It could contain a type, several types, etc. T[0] tells typescript to take the first element of T. If T is an array of numbers number[], it'll be number. If T is an array of strings string[], it'll be string. If T is an array contains both strings and numbers (string | number)[], it'd be string | number. But if string has a precise type, for example [number, string], we know three things: 1) it has exactly two values 2) the first value is always number 3) the second value is always string. As such, T[0] would be number. 0 can be thought of as the type of any number whose value is 0. Because the definition is so precise, it's just 0. When saying T[number], we are asking typescript what the result would be of indexing over the type of any valid number. It's a wider definition, a different type, but the same operation. The valid numbers here are 0 or 1, so the result is either number or string, number | string. Thus, in our example: T[0] is number T[number] is number | string If you wanted to use the type of the values inside T later on, using T[0] could create a bug if T contains more than a single type. When you're making a generic like this, you don't know how it could be used in the future, so you want to cover your bases. What if you forgot days later that your generic flattening type just doesn't work with more than one type per array? So while generics should be as tight as possible for clarity, you should also avoid losing information along the way.

Happy new year Theo!!!

I don't necessarily dislike the choice prettier made. But having the parenthesis at the end of the line while the colon is at the start is a net negative to me. I'd much prefer for both to be at the start. With your example, I'd prefer: type Something = T extends string ? T extends "a" ? "a" : "b" : T extends number ? "number" : "other" If you if else can't be at the same level, I'd at least like both paths to be, just like in regular programming. Questions in languages are already annoying in that you must rely on other clues to determine it is a question, as the question mark comes at the end. Taking hints from natural language isn't always great.

I do quite like ternary operations in my code, but I do find that a good rule of thumb is to fit them in a single line. If one spans multiple lines, consider another option. As small as possible, and no nesting. Then they become clarifications rather than obfuscations.

Well, I often use ternaries (in rare cases even nested ones) to make the code in my webpage's JS smaller and less to type. For example, I have a function that generates a lot of numbers that in the end should be packed into a string with the backtick string functionality. Instead of writing an if/else statement I just type the string template and in the optional parts I put a ternary to either place the number there or if it's a certain value put a placeholder or nothing there.

I've always ended up putting a lint rule to block and nested ternary. If you need that level of complexity to figure out what you should be rendering just make a function

I already was subscribed, so I don't understand why the type error, but I loved the gag! :)

OOP brain goes "this conditional statement should be several objects, actually"

Rule of thumb I use in the code review is that the "short branch" should go first, then you can reduce the mental cost of keeping the context of the ternary

Happy new year. Creating a bunch of functions and components can also just make a file hard to organize.Personally I had to develop a system where I move functions around so similar functions are closer in the file

@hannad

6 ай бұрын

Too many files. Too many components In a file. I have heard this countless times . All of this is just messy. We are convincing ourselves that this is better than that. I think the whole jsx was a mistake. But there is no better alternative aswell.

@ccgarciab

6 ай бұрын

Just Svelte, guys

Top tier subscription reminder with the literal type 😂

@DavidWMiller

6 ай бұрын

Made me rage quit the video 🤷🏻‍♂

6:10: you may use ternary inside your component to avoid multiple return paths. function Sidebar(props: ...) { return (props.sidebarOpen === false) ? null : { Sidebar : }; } Turn that into an arrow for even less bloat: Sidebar = (props: ...) => (props.sidebarOpen === false) ? null : { Sidebar : }; } Same for UserInfo. Ternary are not the problem. Mixing code and html definitely is.

6:57 loved that type error

Happy new year!

My code review notion, see more than 1 level of ternaries, your PR is rejected.

I haven't actually made use of ternaries in js but my immediate thought was regarding your usecase: What if you use the ternary like it's an if guard? Invert the boolean check so null is specified first.

@9:23 ternaries are an expression (meaning they evaluate to values), while ifs are just a control flow statement that don't resolve to a value on their own

I loved this video! Great content Theo!

Hello wonderful person watching this wonderful video

@obaid5761

6 ай бұрын

Hello wonderful person opening the replies to the comment of a wonderful person saying hello to all you wonderful people

Interrupted New Year’s party for the anxiety of ternaries.

In my opinion, the example with more components was not "clearer", but for a big ternary example, I can see why it would be better.

@a-yon_n

6 ай бұрын

You don't have to use ?:, you can instead use !!

6:35 This pattern could lead to performance implications though. What if Sidebar needed to query some user data using a hook? Since hooks can't be called conditionally, we'd have to run the query even if the sidebar is closed. It would be better to just not render Sidebar at all by conditionally rendering the component in the parent

@iceinvein

6 ай бұрын

depends on the query you can choose to run the query only if sidebar is open

@arjundureja

6 ай бұрын

@@iceinvein Sure but there could be many other side effects as well. It could get messy to conditionally run all of them

@lord_kh4n

6 ай бұрын

Mind you that this is just an example, so different solutions are still required to be researched

I like have a rule on using ternary 1.) Don't make it complex. 2.) Avoid Nesting if possible. 3.) Use component if really big (optional). 4.) (Tip) If possible I make my ternaries readable. Idk if someone does the same (Let use the example in this video) { (sidebarOpen === false) ? //just by reading this line you know'll encounter a ternary. null : //if userInfo is false Don't render just show the sidebar Else render it with the sidebar. }

Happy new year bro😂😂😂😂

Happy new year 🎉

JavaScript absolutely needs switch expressions like c# or the when expression like kotlin. Kotlin also has if-else expressions instead of ternaries

@jfftck

6 ай бұрын

This is pattern matching, I hate the reuse of the keyword switch when the term match would make more sense.

@Bliss467

5 ай бұрын

@@jfftck match is great. I also like when. Switch never made sense to me.

4:14 whats the logic behind wrapping the arguments into props?

@loic.bertrand

6 ай бұрын

I guess it avoids repeating parameter names (for actual parameters + for types). It also makes it clear on usage when a variable is a prop or not.

I had a discussion about whether we should allow ternary. In the end I managed to convince to prevent using a ternary operator in a ternary operator. It's also that the operator precedence of the ternary operator over other operators differs between languages. And it's also different on right or left associative (so calling the right ternary or the left operator first). PHP even changes it after version 8! Still when it comes to clarity && is not clear to everyone. I started programming in C++, so I'm used to these types of hacks.

Happy new year

“That’s not ugly, that’s readable b****” - 11:20 - Was not expecting that 😂. Great video overall

2:50 Just invert the ternary and you get your top-to-bottom reading back. That's just what you ended up doing, but inside some components.

my favorite ternary syntax looks like this: condition ? if-value : else-value then all nested ternaries get indented as well: condition1 ? condition2 ? ifvalue2 : elsevalue2 : elsevalue1

Separation of concerns should be the first goal for sure.

One of the things I liked about templating languages like handlebars was how readable they were (of course they have their own shortcomings). I do agree with the arguments for encapsulating the ternary behavior for readability. However I also agree with the argument that doing so will put the responsibility on the encapsulating component for worrying about state outside of itself, and the parent should probably be the one determining whether a component should show or not. What about a nice middle ground such as creating a conditional component to handle this behavior? If we have a component that encapsulates the behavior, we can leave the inner component to worry about its own state, and the parent still gets to determine whether the child renders or not: //

What about the use of ternaries in tailwind classes? For me, I have no problem with it especially when the class depends on state.

whoah... Theo did some OOP abstraction. What a time we live in.

I sometimes use a function inside that jsx syntax so I can use if statements

🎉 Yup. This is really good practice. I use tenraries a lot but never in react jsx but even still, I'm finding more and more just preferring to use an if guard statement.

Any time I make a new component my job requires me to make a new unit test suite and Storybook story for it so I tend not to make new components if I don't absolutely have to

and no this ain't some obscure esoteric lang - the function in the screeenshot is POSIX-compliant awk syntax

The JSX case is a great example of overengineering like with creating factories for everything in joke “senior” code. React docs itself recommend to check for condition before rendering component like {showUserInfo && }. The early returns in function is more like an anti-pattern until your are doing something like Chain of Responsibility (which is not a case here).

what a great way to start the new year 🤣

Every day I see the wild shit like this, going on in web-dev languages, I become far more grateful for being a C# developer.

@svenmify

Ай бұрын

There’s a lot of weirdness going on in blazor too (I like it a lot, but there’s still weirdness)

Ternaries are only to be used with one line assignments/function calls. This should be the standard.

what about using the nullish coalescing operator (??)?

thank you for clarify

First video I'm watching in 2024, have a nice year guys

I definitely prefer top-to-bottom readability to DRY/concise.

I think short and concise with proper formatting, where you can see the entire functionality in one reasonable component is much preferable to breaking up everything into an endless number of little components which all they do is an if check and then depend on a number of other components. I find trying to track down many components and how they fit together in my head much harder than reading a component that's a little bigger because it has a couple conditionals in it.

@H4KnSL4K

5 ай бұрын

Like isn't actually doing anything, itself! and you're repeating the names of these variables too. You could repeat this endlessly..

I think ternaries with "Clean Code", that is putting names on each path, is readable, but not inside JSX.

Not about ternaries, but I think you should never do this kind of check if a value is falsy like "something.length && ..." or "if(a.length)". It is a tiny bit more work to write out the full condition with "!== 0" but it makes things more clear and more well defined. If youre not careful you will also end up doing weird things you didnt intend to do. For example, if you want to check that a variable str that could be null or a string is not null and you do this implicit check, an empty string would be handled the same way null would be handled. And even if you want to do that, write out two conditions because then at least people will know that both parts of the condition are intended and you didn't implicitly check for multiple conditions by accident. And these hacks people do with the !! are the weirdest thing. You feel so cool when you shorten your code by 4 characters but all you're really doing is making your code less readable. An example of implementing ternaries well is Kotlin in my opinion. The language doesn't have the classic ? and :, but instead an if statement is an expression. You can do something like "val x = if(...) { ... } else { ... }". It is more concise, allows you to handle cases where you have more than two possibilities in a readable way (else if rather than chained ternaries) and you can also write proper code into the blocks and arent just limited to returning a value.

@coredeadman5980

6 ай бұрын

You can also do !!something.length && ... 😂. Not that readable, but it is now a boolean and not a number anymore xD. 7:53

Those ternary expressions were easily readable

Ternaries are totally fine if they are used for very simple things like variable assignments.

I would have thought using a debugger was on the list of things nested ternaries make harder to do

@GenghisD0ng

6 ай бұрын

Idk console.log seems to be working fine

@dputra

6 ай бұрын

​@@GenghisD0ngIMO it's better and much faster to put a breakpoint. You basically get your own steering wheel, pause and inspect each line, giving you better understanding of how a code works without reading the whole program.

Amazing content!

I feel that if you let a bunch of developers consciously format these, some better patterns would emerge for different situations.

I think && is just fine if you don't overdo it. I mean if the codepiece is really complex you may outsource it into its own component, but even then i would put the condition into the outer component with &&, since it is really easy to read and understand for me that way.

I am of the camp that pattern matching should be in every language as it is the most readable option for returning values based on conditions - especially when multiple values are possible.

Just create a component

would you say macs are making VSCode less efficient ? I only ever used windows/linux

@Exilum

6 ай бұрын

It's a good question. I don't know myself. However, I doubt any of us use vscode for efficiency.

@31redorange08

6 ай бұрын

Relevance?

In JSX I really like the component by SolidJS, you can very easily implement it in react: function Show({ when, children }) { if (!when) return null return children }

@echobucket

6 ай бұрын

It's sad in 2024 that React doesn't have the equivalent of and from solidjs built in....

6:47 I love this!

Aren’t regular if/else statements also faster than ternaries?

Amen brother. I've been a front-end developer for ~20 years and a staunch advocate for avoiding nested ternaries. I haven't really found any cases where I've preferred them. Ternaries in general can be hard to follow, consistent formatting across the JS/TS/JSX landscape at least makes them more palatable, but agree that nested is still awful. I would much rather see an "ugly" if/else chain that allows for easier to (mentally) parse code.

@DrPizza92

6 ай бұрын

Been doing this for a long time too and I flat out can’t read nested ternaries.

@chrishyde952

6 ай бұрын

Did ternaries even exist 20 years ago? Not being able to read valid code isnt an excuse to dismiss it. Its a preference

@clipesdaora

6 ай бұрын

​@@chrishyde952 lua, c++, c..... nothing new

@jvdl-dev

6 ай бұрын

@@chrishyde952 yes, ternaries have been around for much longer than that, in JavaScript they were part of the original language spec. While I agree that whether or not I use nested ternaries is a preference, I disagree with the premise that just because something is valid code it shouldn't be criticized if the way it is used makes it harder to read the code. I'm not _dismissing_ ternaries, but rather advocate for taking the most readable and understandable approach. Which IMO in many cases means that nested ternaries would be better off being rewritten.

Why didn't anyone think of making a Show component like in Solid for React and an If component? But now I'm writing my UI library in which I added this, first of all, and other components that help to control my Switch type markup, and the most interesting thing is the Slot, which for some reason no one made for React

Not being able to read the code is not the ternary's fault

I tend to find it more readable if the syntax is fairly terse (not ridiculously terse like array programming languages) and unless you're reusing a function or component; I usually prefer large functions/components over a bunch of small ones. While I've always been prone to write rather large functions; when I was younger I found myself splitting out in to sub-functions a lot more than I do now, these days I will usually only split out sub functions if it makes the code significantly shorter or of it makes scoping easier... I will often even often restructure the code so that I can use fewer functions if possible. End I wonder if it's not only experience/old-school preferences, but also physical aging. I need bigger fonts to see well these days (I no longer prefer dark mode during daytime either because my eyes need more light); and I've always preferred usning a single and fairly small monitor for coding (too big screen means a lot of wasted white space blasting light at me, or distractions in my peripheral vision if I use non-maximised windows); so with a larger font I have less screen space than before and code is much easier to reason about when you can see all the relevant parts at once. And while ternaries have the disadvantage of using very small symbols; at 18 pt font size they're still quite visible. And I really can't stand (and I never have) having the logic of some feature split over several files. I despise languages that require you to put each thing in it's own file, because those implicitly requires you to split your logic over several files if there is any code re-use at all. But I'm sure for the kids who write code in microscopic fonts such as 10 or even 8 pt it could be hard to see a colon since it's a just two faint antialiased blobs. And if you write in microscopic fonts, and maybe even use huge and multiple monitors, maybe having the logic split up into dozens of verbose named functions or components doesn't bother you as much as it bothers me, because you can see the whole content of maybe four 80 line files at once; while I normally can only see around 35 lines of one single file at the time.

What we really need is expressions like rust has, like const x = { if(something) return 1; else if(somethingElse) return 2; return 3; } Same as immediately called function, just less awful. const x =:{something} is way better than const x = (()=>{something})(). Even if it does have a very upset face in the front, it's probably way less upsetting than deep ternaries. Maybe even omit curly bracers, like const x =: if(a) return 1; else if(b) return 2; else return 3 or even omit returns. Though I can already see people doing side effects in this, that would be a mess. Not that you can't do side effects with ternaries, I'm guilty of console logging stuff during jsx render for debugging myself. I've used them, it's been a pain. Especially whenever there's something recursive to do with a deep type that has to support plain types, objects and arrays. I don't think there's a way around doing T extends ValueType ? ... // string, bool, number etc : T extends any[] ? ... // arrays, you can recurse with the single element with T[number] : ... // objects, do a mapped type or something like that.

4:45 but in vue and probably in svelte (i haven't tried svelte yet) you cannot just return null like in react. In those frameworks you always need to define condition in the template.

I'm a bit concerned that Prettier is trying to justify that nesting ternaries is a good idea. the only case i ever see for a ternary is if you're doing a conditional spread in an object or array and then doing `{ ...myObject, ...(isThisThing ? { field: 'some value' } : { otherField: 'some other value' ) }` because although you can do ` ...( isThisThing && { field: 'some value' } )` that same doesn't work with arrays and you'll have to ternary arrays. So it just keeps that syntax similar. i do agree that if/else is messy, but that's why doing early returns with if checks is a lot cleaner than if/else blocks. A ternary is used it if it's a dichotomy, so just doing if (!notThing) { return } and then having your other logic continue below for me is a lot easier to read, and can often stop if/else nesting as well. And if it has a lot of conditions that's where switch statements or maps are useful. Because i totally agree having good legibility in your code is key, being able to come back into something months down the line and not feel like you're tiptoeing through cryptic but concise code is a godsend for refactoring, making changes, or just reviewing

The company I work for loves ternaries, complex ternaries, 5-10 nested ones.

yes, it's so much better to call a function and return null immediately

0:40 i had this one time, it was a nightmare to figure out

thank you

6:47 good one ;)

just use switch statements? switch(true) { case : return stuff }

I think kotlin does this better because if-else can be used as expressions. For example: val number = 0 val result = if number > 1 "greater than one" else "not greater than one" IMO that's just a better solution.

4:51 so like a guard clause...

I agree with the top to bottom going into left to right, that is annoying to parse... The linter we use forces all JSX to be wrapped in parens with new line after start/before end. This way it's just reading top to bottom still even with the ternaries. Granted, I also would push back on nested ternaries. I'd rather just put the new ternary in a new component. Though, I am pretty interested in trying to do the return null flow you show here instead of ternaries in general.

I really like that new formatting. Reads almost like if-elseif-else code. Although I agree that you should avoid nested Ternaries as much as possible. But the next time I run into code where a prior dev has a bunch of nested Ternaries on a single line, I'll happily reformat it to this before trying to read it.

6:57 was a flex and I’m offended

You can still use ternaries and split code into multiple components

I love javascript, truly. I don't like jsx. I just program everything in javascript, html, and css. I like it more that way, and I get to learn how to make things fast by understanding javscript better, instead of muddling through with react and compilation which slows me down too much, honestly. The only thing that really slows me down now, is finding why the NaN value is happening after refactoring, but I'm working on a tool to help with that... Maybe it will be out soon. In the mean time, it's happened so often now that I know what to look for. 9 times out of 10, it happens because of division or other mathematical operations with an undefined variable.

i've been asking and pleading for JSX directives proposal for ages

is this just "make smaller less complex functions" but for components? Edit: Flatten = T[number] works for me just fine btw :3

I've always hated ternaries in markup, never thought of doing it this way, much better!

The more I know about react, the more i like Angular

Sometimes I wonder why people would even need to do a `contacts.length && contacts.map`. The map would simply just not return anything if the list is empty, so it's kinda pointless to check for it.

The benefit of ternaries over control flow is they are expressions. You "can’t" nest them to oblivion with different mutations and other statements. I generally think of the else keyword as a code smell that should be a guard clause instead. I also ensure the simplest outcome of a ternary always comes first, e.g. !foo ? null : bar.baz?.name

I subscribed long time ago :D

The problem is JSX not ternaries. React users pretend JSX is superior in every way, when it can't handle basic loops or conditionals without a hack.

@MrMatheus195

6 ай бұрын

But the alternatives are as ugly as jsx

@gilatron1241

6 ай бұрын

Blade templates are pretty nice

@AdityaPimpalkar

6 ай бұрын

No one likes this. I don’t like it either, but there is still less adaption of other frameworks like svelte or solid in the industry. Vue is the only one I have seen quite a bit of decent adaptation. Blaming framework users is a cop out thing to do when you fail to see what framework the market still uses and continues to keep using. He is showing how we can use best practices to tackle this

@geoffreyolson9720

6 ай бұрын

Loops? Since when has array methods not been enough? It's easy to read as well.

@IsuruKusumal

6 ай бұрын

I love how compose lets you do simple if-else without hacks like this

I would love if expressions in JS