Love it! My two takeaways of code smells to look for were: 1. watch for components that shouldn't know about other components (ex: your ButtonMenu's Button shouldn't know about a Menu) 2. watch for cross-cutting concerns that cause adding simple features to add code far apart. Aim for functional cohesion
Hello, thanks for the question. Thai here. No new talk about React yet, but I can say that I find most of this talk’s concepts are still relevant to me. But with hooks, how I write components have changed dramatically. If I were to do this talk in 2020 here would be the main differences: ・ 16:28 - I would’ve written everything as function props. I have not written a single class component for over a year now. ・ 18:39 - Even with hooks, the loss of cohesion can still occur. ・ 25:35 - I still use “data connector components” extensively. Now they’re implemented with `useSelector` and `useDispatch` hook. ・ 23:44 - I now have a convention of adding “-Connector” suffix to data connectors. So the `Auth` component I would call it `AuthConnector` in 2020. ・ 25:35 - I would also add that when the “data binding ceremony” happens at one place (i.e. at the data connector component), we can change the data binding implementation, without affecting any other parts of the app. I might show this by reimplementing the Auth component using Firebase Authentication (which has its on authentication storage, so Redux is not needed there), ・ I would have used TypeScript (or JSDoc annotation) instead of PropTypes. Cheers!
It's a quirk kind of. Typing a && b is quicker than a && b : null. If a is falsy in "a && b" then false would be returned, causing react to not render anything. Same goes thing for the ternary expression, but you have to type more. It's a matter of preference.
Love it! My two takeaways of code smells to look for were:
1. watch for components that shouldn't know about other components (ex: your ButtonMenu's Button shouldn't know about a Menu)
2. watch for cross-cutting concerns that cause adding simple features to add code far apart. Aim for functional cohesion
This talk was excellent and very informative! Thank you for this.
Good talk! Practical and useful. Thanks for sharing.
Thank you, good talk. Love Thai and Thai Land : ).
Wow it's such an amazing yet simple to understand talk, good job
fun and informative talk!
Definitely some good piece of advice!
Great talk!
Thanks for the talk, Thai
Damn. This is awesome
Great talk bro! It would be great to see a talk from him right now that hooks exists.
Hello, thanks for the question. Thai here. No new talk about React yet, but I can say that I find most of this talk’s concepts are still relevant to me. But with hooks, how I write components have changed dramatically. If I were to do this talk in 2020 here would be the main differences:
・ 16:28 - I would’ve written everything as function props. I have not written a single class component for over a year now.
・ 18:39 - Even with hooks, the loss of cohesion can still occur.
・ 25:35 - I still use “data connector components” extensively. Now they’re implemented with `useSelector` and `useDispatch` hook.
・ 23:44 - I now have a convention of adding “-Connector” suffix to data connectors. So the `Auth` component I would call it `AuthConnector` in 2020.
・ 25:35 - I would also add that when the “data binding ceremony” happens at one place (i.e. at the data connector component), we can change the data binding implementation, without affecting any other parts of the app. I might show this by reimplementing the Auth component using Firebase Authentication (which has its on authentication storage, so Redux is not needed there),
・ I would have used TypeScript (or JSDoc annotation) instead of PropTypes.
Cheers!
thanks for the useful talk!
awesome talk :)
I have a button , I have a menu, aaah ;P
nice talk
Wow, can't remember if I have ever heard an argument against DRY
what is the difference between
booleanAssignment &&
and
booleanAssignment ? : null
and why you love to use that first case kub?
It's a quirk kind of. Typing a && b is quicker than a && b : null. If a is falsy in "a && b" then false would be returned, causing react to not render anything. Same goes thing for the ternary expression, but you have to type more. It's a matter of preference.
It's easier to read:
isAdmin &&
than:
isAdmin ? : null
The last expression contains just too much noise.
Sounds like Jian Yang