Mithi's Ted Talk on Styling Components

[r002]

On Thursday (3/11/21), @mithi left a really nice and thoughtful comment in one of my PRs. Her comments are so good! Bc the PR is now closed, all of that great info is now sadly lost to the sands of time though... so I wanted to repost it here, if that's okay?

To level-set: Personally, I am a beginner to React. While I did do webdev over a decade ago, I'd wandered away for a good long while (Python! Pandas! Data analytics!) before finally returning to the scene earlier this year. A lot has changed! CSS inline in HTML and JS is now a thing! 😯 What a world. The learning never stops! 😄

---

From PR: #121:

One question for you though: I noticed that in your Make nav buttons closer together change, you directly edited the SqaureButton React component in components/main/navbar.js. While that definitely works, I'm curious: Is there a specific reason you did not create a new "Nav Button" else if block inside of const SqaureButton in components/button/index.js? Or (maybe even better): Create an entirely new NavButton component that extends SquareButton but then just sets the { margin: "5px 10px" }? Generally, I just get nervous when I see CSS getting manually set in the style='....' attribute inside of JSX. Like, I enjoy separating all styling concerns only to be the .css file OR at the .js level inside the actual component (eg. SqaureButton).Does that make? Just curious about your reasoning.

Oh no, you somewhat opened a can of worms here 😅. I hope you don't mind the huge wall of text below!

Disclaimer: Note this is just an opinion, I'm not saying this is the best way to write this code, these are the things that go through my head as I was writing it... there are always tradeoffs! Don't get me wrong, I also like putting the styling inside the actual component... but there are other considerations here... (other than I can't put styles in a class because of specificity, it won't be able to override the styles inside the SquareButton component)

(Also notice that I slightly refactored NavInner, without making a new component (I double down on that)...I hope you like it 😅)

epic-react-exercises/components/main/navbar.js

Lines 33 to 39 in 57e5cdf

	<SquareButton
	onClick={() => changeMenuState("react")}
	{...labelProps("react menu")}
	{...iProps}
	>
	<FaReact />
	</SquareButton>

Adding an if-else block is not a good idea...

The SquareButton is intended to be a general reusable component... Taking a look at the source code of SquareButton

epic-react-exercises/components/button/index.js

Lines 119 to 121 in 9af49d5

	const SquareButton = ({ side, style, ...otherProps }) => {
	if (!side || side === "small") {
	style = {

You'd observe else if block is only for checking the side prop which can either be a falsey, large, small or some size like 15px for example. You might realize now that wouldn't make sense to add additional specific cases like NavButton or PaginationButton or ThemeMenuButton as it would go on and on and it goes against the api...

I read this

I have often found myself writing my API before I have even decided how I'd like to interact with it. After watching this series, I have started to write what I would expect my API to provide before actually writing it.

And I realize that I'm guilty of this, so now I try to think about the api first before creating components!

Yes, I thought about NavButton

because that's how I approached the reactMenu buttons the react menu As you can see here:

epic-react-exercises/components/main/react-menu.js

Lines 6 to 16 in 9af49d5

	const Button = ({ children, section }) => {
	return (
	<PlainButton
	href={`/react/${section}/1`}
	style={{ padding: "15px", margin: "6px", fontSize: "18px" }}
	className={styles.reactMenuButton}
	>
	{children}
	</PlainButton>
	)
	}

But there are other considerations

duplication is far cheaper than the wrong abstraction - Sandi Metz

Here's some highly recommended reads/talks about this you haven't already!

• Sandi Metz: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
• Dan Abramov also has an interesting talk called The WET code base https://overreacted.io/the-wet-codebase/
• Kent C Dodds: https://kentcdodds.com/blog/aha-programming

Helper methods are object junk that we need to recreate and compare for no purpose other than superficially nicer looking syntax - Dan Abramov

React has a powerful composition model, and we recommend using composition instead of inheritance to reuse code between components.

It's nice to read and watch about Composition vs Inheritance

• (This is one of my favorites) Using Composition in React to Avoid "Prop Drilling" by Michael Jackson https://www.youtube.com/watch?v=3XaXKiXtNjw
• https://reactjs.org/docs/composition-vs-inheritance.html

About separation of concerns

I'm not sure if you've tried tailwind but here's a quote from their site

Now I know what you're thinking, "this is an atrocity, what a horrible mess!" and you're right, it's kind of ugly. In fact it's just about impossible to think this is a good idea the first time you see it — you have to actually try it. But once you've actually built something this way, you'll quickly notice some really important benefits.....

Read more: https://tailwindcss.com/docs/utility-first

I know that not a lot of people may agree with it as you can see in the discussions from hacker news

• https://news.ycombinator.com/item?id=22628463

But based on my experience...

When you realize how productive you can be working exclusively in HTML.... working any other way will feel like torture.

That's all! Thanks for coming to my Ted Talk!

[mithi]

Bc the PR is now closed, all of that great info is now sadly lost to the sands of time though... so I wanted to repost it here, if that's okay?

What do you mean it's lost? Isn't it just... still there? 🤔

[r002]

Sorry, I was unclear! 😅 I meant "lost" in the sense that since the PR is closed, it won't be easily visible to any new visitors to the project. My understanding is that the only way to find that specific comment is to now navigate to closed PRs & then read through each one. I just thought by resharing here in "Discussions", your comment would be more easily findable to any first-time contributors newly visiting the repo, since it's front-and-center.

…

On Fri, Mar 12, 2021, 10:46 AM Mithi Sevilla ***@***.***> wrote: Bc the PR is now closed, all of that great info is now sadly lost to the sands of time though... so I wanted to repost it here, if that's okay? What do you mean it's lost? Isn't it just... still there <#121>? 🤔 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKZOWQXMPSHSBMZF7EFH7WDTDIZMPANCNFSM4ZCMTTNA> .

[mithi-aeronology]

[r002]

@mithi-aeronology New account?!

Amazing doc! Will send thoughts over this weekend!

Hope you're doing well! Very lovely to hear from you! ☺

[mithi]

@r002
Ooops sorry I used my work github 😓