Forem: Guilherme Samuel

3 Popular eslint rules that can make your write worse code

Guilherme Samuel — Fri, 28 Apr 2023 01:54:25 +0000

Eslint is a successful tool to maintain style consistency across the codebase. The problem with it is, if you follow some rules blindly it can lead to worse DX, nonsense refactors and more verbose code. Below is a list of 3 rules that most likely you'll want to question if it's really worth it for you and your team:

1. Prefer default export (from airbnb style guide)

I did drop default exports for a year now to use only named exports and they are actually (a slightly) better option. They provide a better DX, since you'll have autocomplete. The downside can be conflicts (which can be solved using an as to rename it). Don't refactor your entire codebase just to use it, but keep in mind for the next projects that named exports has better tradeoffs.

2. Consistent returns

Keeps you from doing such a very practical pattern (early returns). Is likely that you'll end up taking some unnecessary time to refactor your code to a less readable version

3. No param reassign

There can be compelling reasons to avoid param reassigns, but this downside is minimal given the benefits of a more readable and less verbose code where you just reassign the value from your parameters.

Remember, you don't have to go through a worse experience and do nonsense refactors just to conform to some rule imposed by someone else. When a rule is enforcing you (and your team) to write less readable code, question it, and just disable it if isn't a good idea.

Biggest groundbreaking solutions in the React ecosystem

Guilherme Samuel — Sun, 19 Mar 2023 22:35:13 +0000

It's not something unknown that one of React biggest strengths it is ecosystem. It's so powerful, that although React could (unknowingly) have big pain points, they were solved gracefully by other libraries. This article attempts to acknowledge each groundbreaking solution.

Data fetching with React query (tanstack query)

Before it, we tried to pretty much think and imitate lifecycles with hooks (because we carried this mental model from classes), leading to dirty effects, a lot of repeated state everywhere, waterfalls and bad implementations to handle complex problems like caching.

RQ pretty much erased a lot of app's state, with powerful defaults that already improved our apps UX (by refetching on window focus, having retries when requests fail or when the user's internet reconnects) and abstracting a lot of work we would have to do in every single app.

I think this is by far the library that aggregated the most value on the React community and it should be the default to fetching data on the client (while use isn't ready yet). On the server we should be using what the framework provides.

State across components with Zustand (previously Redux)

Initially, we had some problems to solve related to state management. One of the most popular was prop drilling, which in order to solve it we started using a huge bloated library with a lot of boilerplate (Redux). We needed a stick and they gave us a nuclear bomb.

Eventually, Redux got much better when toolkit came, and still is a great solution today, but for most apps, state management can be solved with a simpler approach. People started migrating to the built-in solution Context API and what happened was interesting, it started to be overused and even having a negative impact as we were reinventing a worse implementation of RTK itself.

This is where this gap was filled nicely because with Zustand, we now have a tiny, but flexible and scalable API. Creating stores, updating and reading state is much much easier nowadays.

Forms with React hook form (previously Formik)

Everyday a new React dev complains about how difficult is building forms using React compared to other libraries. This completely changed for the better with hook based approaches, initially with formik (that sadly has performance problems), but now with an even better API and performance focused solution, React hook form, killed our needs with easy to build validations, transformations, etc. It cover a lot of use cases and can scale very well (personally I've saved a lot of hours by reusing a form and input components that have been registered using useFormContext).

Performance and SEO with NextJS/Remix

For years we developed rich client side apps, to only realize that we were shipping a lot of JS and having sub-optimal SEO as HTML wasn't being printed for the crawler.

This only became obvious when NextJS came as an abstraction that was pretty much focused on generating content as static as possible, eventually leading to generally faster React apps.

It was just too much work to build a SSR app yourself, so having a framework which already save us hundreds of hours by giving us the ability to pre-render content ahead of time showed up to have a great UX in the end, but also led the community to a shift from client side only focused apps to using the server to save as much JS as we can. This shift is still happening these days and only in a few years we will realize if it's all worth it.

What's next?

The future of React is exciting and unexpected, as there are problems we don't fully acknowledge yet, which still can not only be solved by the core team, but by our awesome community as well. Either way is always a great option to think deeply about the pain points we encounter in every new project, so we can start digging deeper and hopefully find new solutions.

ChatGPT is a regex god

Guilherme Samuel — Sun, 12 Mar 2023 21:36:31 +0000

ChatGPT can give you statements that either:

Sounds very truthful, but has something wrong with it
Is surprisingly good and accurate

With Regex questions, it seems to weigh way more on the latter.

A few examples:

Match a Reddit post URL
Match a Twitter reply
Match a document format from a country
Match any email address that ends with "gmail.com" and contains a plus sign (+) followed by any combination of alphanumeric characters before the @ symbol
Match any phone number in the format (XXX) XXX-XXXX where the first three digits cannot be 555

Be careful, it's prone to mistakes, so it's always a good idea to test it on an app like https://regex101.com/

Overall, I feel like most of the generated regular expressions are already going to be good enough to save some valuable minutes of your life.

3 Simple ideas for a better ReactJS

Guilherme Samuel — Sat, 04 Mar 2023 21:52:14 +0000

React has certainly made a notable stride on the quality of our DX. Features like hooks were major breakthroughs on how we develop client side applications. It is important to note however, that even though React has matured a lot, there is still plenty of room for innovation and improvement. We're currently heading towards a merge between the client and server, which is going to be a costly shift in the things we are going to have to deal with and care about. I hope that these long term plans work out, but while we watch this progression, I have a few ideas that could impact React on the short term.

1. Bring something like a platform-agnostic Zustand

Zustand is a simple state management library capable of covering most of our needs of small to medium size state complexity. It has an insignificant learning curve and solves the problems of using state anywhere much more gracefully than the current built-in alternative way of accomplishing it (context API, which isn't a state management library to begin with and needs to be tied to a parent component). Bringing something like this to the core would encourage the simplicity and easiness that Zustand tackles state managemente.

2. Release the docs as it is, improvements can come later.

It is been several years since the docs are outdated. Still using hooks. The perfectionism here completely outweighed the benefits of just releasing what is already good. It should be released a while ago, even if we don't have a proper landing page.

3. Make the React DevTools relevant again.

I don't know if is either because a core contributor isn't there anymore or the roadmap was completed, but this project is pretty much stale.
As we're moving towards SSR, would be useful to have some new features there to help us debug server related problems, for example:

Possibility to go back between renders to check the differences between server and client (to better identify hydration mismatches)
Visualize suspense data
Check for waterfall requests
See which components are RSC and which are client, etc

Implementing these short term ideas could have a significant impact on the React community and make our development experience even better.

3 Things I wish I knew when I started as a dev

Guilherme Samuel — Sat, 18 Feb 2023 17:08:05 +0000

I wasn't as great as I thought I was.

When I started as a front-end developer, I thought I knew almost everything about CSS, HTML, JS, and React. I had the common misconception of thinking I was proficient and could tackle everything, when in reality, I just wasn't aware of how vast the programming universe is.

It's a dangerous place to be when you're falsely sure you know that much, because it can diminish your progress and trick you into thinking you already know enough. Also, it's possible to get stuck forever here if somehow you don't realize how big it is. Luckily I could go past this phase, but I wish that happened a little bit earlier. Nowadays, the deeper I go, the more I understand how huge it's.

Just coding wasn't enough. I needed my communication skills in place too.

The first unexpected moment was in interviews, being asked to describe what I had worked on before concisely. Later when I got the job, this skill was even more requested on standup calls, plannings, reviews, retros, and other meetings.

Being able to communicate and express myself clearly was just as important as my technical skills. If I knew this from the beginning, I would practice it more, potentially making it easier to climb the promotion ladder, because the far you go there, the more important it is.

It can be exhaustive.

I never thought that by doing what I liked and earning some cash along the way, I could get mentally exhausted. I wasn't aware I would encounter crazy deadlines, unnecessary arguments, finger-pointing, excessive extra work hours, constant everyday pressure, undervaluation, chronic stress, and consequentially, burnout.

It happens, a lot. If I had known about it earlier I would say no to a lot of things, giving myself more room to breathe when needed.

As a dev, what knowledge or skills do you think you should have at an earlier stage in your career?

Better way to think when creating components

Guilherme Samuel — Sun, 12 Feb 2023 21:14:20 +0000

When in doubt of how your component should look like and what it needs to support, start by how you would consume it. A few examples:

A dropdown which will receive a title and the content (which should be able to also receive JSX). An icon will be optional:

<Dropdown title="My title" content={<p>My content</p>} />

<Dropdown icon={<MyIcon />} title="My title" content={<p>My content</p>} />
// Now you know you need to accept an optional icon (ReactNode), a title string and the content (which is also a ReactNode)

A customizable flexible card with a lot of different variations:

<Card>
  <Card.IconWrapper>
    <MyIcon />
  </Card.IconWrapper>
  <Card.Title>My title</Card.Title>
  <Card.Content>My content</Card.Content>
</Card>

<Card>
  <Card.Title>My title</Card.Title>
  <Card.Content>My content</Card.Content>
  <Card.IconWrapper>
    <MyIcon />
  </Card.IconWrapper>
</Card>

<Card>
  <Card.Title>My title</Card.Title>
  <Card.Content>My content</Card.Content>
</Card>
// Now you know you'll need to create separate components (title, content, iconwrapper) and assign to the main card.

A sidebar that I can just pass a structured data to it:

<Sidebar
  items={[
    {
      name: "Home",
      icon: HomeIcon,
      link: '/',
    },
    {
      name: "About us",
      icon: AboutUsIcon,
      link: '/about-us',
    },
    {
      name: "Terms and conditions",
      icon: TermsIcon,
      link: '/terms',
    },
  ]}
/>

// Now you know you'll need an items prop, which you'll loop for each item and render the name, icon and pass the link as a href.

Instead of starting with the solution right away, a better approach may be starting by the use cases, which you will know more carefully what you need to build in order to support your needs.

Sorry, but everything is a tradeoff

Guilherme Samuel — Sun, 05 Feb 2023 17:54:10 +0000

You just used a library, it's now your favorite one, it worked well for that project.

Now you want to use it for every single project from now on...

Stop.

Take a step back and analyze each pros and cons considering the new needs.

Technologies were created to solve specific problems, your Astro blog project was successful, but that doesn't mean you'll have the same results for a heavy dashboard (probably not, astro itself is focused on content heavy websites).

Your zustand store worked very well for managing your theme. It doesn't mean you should also use it for on your new event managing app with large amounts of state that will have some complex logic to update it (redux, yes, may be a more appropriate option)

There's no silver bullet in our field.
(except Tailwind, use it everywhere you can because is that good /s)

Disclaimer: It's important to say that stack choices aren't always made seeking the most appropriate tech stack for the project, but it's also a combination of other factors (for example you have to consider your team skills as well)

You did css wrong

Guilherme Samuel — Sat, 04 Feb 2023 19:59:13 +0000

We've been writing css on separate stylesheets for a long time. This separation was already the goal of HTML in 1990, so we could apply styles globally and reuse them. This has some solid advantages, for example if you want to apply a color to every p element, then you just need to do it once. Also, if you need to change that color again for all the elements, it's only a one place change.

So... it seems it's all good, but at what point did we mess up with it?

Custom classes

Later on, as our designs started to get more complex and websites were transitioning from simple chunks of text to fancy layouts with buttons and links, we needed more appropriate ways to style that could fill our needs of customization.

To solve this problem, we started using classes and... well, this is the point where we were sinking and didn't know about it.

The workflow pretty much changed from "I apply this style to this element on my website and it will look the same everywhere" to "I need to give an identifier to this specific element so I can apply certain styles to it on a separate file, which is far from where the elements are being placed".

Which is just... Awful. Having to assign an indentifier on a file, then going to another one and editing it just to apply some specific styles is horrible, it is killing one of the most important principles we can have on our codebase, colocation.

Things make more sense when they're close to where they belong to. Styles are connected to the markup. Think about everytime you had to change a layout structure. In order to do so you had to apply not only css, but change your html. It means they're very related to each other. Doing it on different places make things more hard to find and edit, consequentially making you way more slower.

The need of something better

With the possibility of reusable pieces of elements (components), now it was possible to apply and maintain a certain style colocated where it makes sense, but the solution we had at the time (inline styles) had a few considerable drawbacks, most notably not having a great DX, being generally slower and enforced as a bad practice in general.

The evolution

It was only some years later that we had something that could beat all of this drawbacks, bring the same pros as inline styles, plus theming and more. Full utility based class names changes everything, now you have all the colocation advantages, purge of css and even more speed due to your ability to spread what's on your mind right there, at the element, with shorter utility names.

How this applies to our web dev world?

I'm still trying to mature this argument so every opinion is much welcome, please comment what you think!

Solutions like tailwind are not only a superior approach than specific css libraries, it strikes on a much more higher level, it is a better approach to styling markup which can reuse it's elements (is not specific to html or css).

Why isn't this some common sense now?

These solutions like tailwind are getting more and more traction, but there's a huge problem for their adoption.

They only make sense when you use it. Is easy to get into thinking is shitty by the looks of it, because it's different from what we've being doing for years. Only when you work with it (and honestly people don't try things, they just judge it first) you start to see the abyss it is compared to separate style sheets. In a week or so they would realize they're much, much faster.

Seriously, if you use tailwind for some time, try going back to separate css files, it feels so wrong even though we did it for many years.

But I think that's normal, we still have so much to progress on our dev world that we'll look into things we do today a few years later and think holy shit, that was bad.

This is the case of using separate css as a way to style all of your components.

Typescript + tailwind = typewind (first impressions)

Guilherme Samuel — Sat, 28 Jan 2023 23:05:43 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1617880004846825474-553'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1617880004846825474&theme=dark" }

This article is about my first impressions with the library, if you're looking to getting started typewind, read https://livecode247.com/typewind-the-magic-of-tailwind-combined-with-the-safety-of-typescript

I decided to try out this promising library by implementing it on their own website! I believe judging a tech without trying it can lead to huge misconceptions (just like everybody hated tailwind until they tried it). After finishing the refactoring I had some thoughts worth sharing it:

Pros

It embeds pretty much every tailwind positive point and at some important ones like productivity, it seems to come even better. The ability to just keep typing what utilities you want - dot after dot - seems ever smoother than tailwind classes.
Multiple utilities for the same variants (this feels good). Tailwind doesn't support this for very understandable reasons, but with typewind this is completely functional. See a comparison below

// tailwind
className="focus:outline-none focus:ring-2 focus:ring-slate-400 focus:ring-offset-2 focus:ring-offset-slate-100"

// typewind
className={tw.focus(tw.outline_none.ring_2.ring_slate_400.ring_offset_2.ring_offset_slate_100)}

It actually will catch some mistakes that any tailwind plugin wouldn't be able to. By converting their website, I frequently got type errors because they were actually using nonexistent utilities (bg-black-500, offset-slate-50). This is important because it will ensure we're not messing up our styles. It's easy to not see a minor tweak like a light border not being applied.

Cons

On the same way that it increases tailwind positive points, it also worsen the negative ones. Readability is even poorer than the inline utilities because there's no space between each utility. Prettier also seems to make it worse by not "inlining" them:

<p
  className={
tw.text_xl.font_medium.text_gray_400.md(tw.text_xl).mx_auto.max_w_full.w_[
      "880px"
    ].text_center.px_4
  }
></p>;

(At the time of writing) it lack of support for relevant features, like color opacity and the important modifier
A little bit unfair to say, since the library didn't reach a major release, but is not tested, prone to bugs and very probable that lacks support for a lot of features (we didn't try yet to discover).

Conclusion

Typewind has a lot of potential and I believe it will be successful if they figure out how to keep the advantages of Tailwind while minimizing the limitations of their approach (which use objects and properties instead of strings).

The crucial positive point for using this library in the future will be type safety. As I said on the pros, it's actually more common than we think to have nonexistent utilities being applied.

What is your opinion about it? Thanks for reading and see you next time :)

How to use the GH CLI with 2 accounts

Guilherme Samuel — Thu, 26 Jan 2023 00:13:23 +0000

This article solves the following questions:
How to use gh with 2 accounts, how can I use gh with 2 github accounts, multiple gh-cli accounts on one machine, github cli multiple accounts

It's incredibly boring having to do a gh auth login every time you want to use a different account. Today we're going to learn how to solve that by using an extension which allows us to create multiple profiles and switch between them based on the current directory. To do so, the steps are really simple:

Install the extension
gh extension install gabe565/gh-profile
Create your first profile
gh profile create [NAME]
Login as you usually do
gh auth login

Now, you have created a profile with an associated github account. You can create other ones too by following the steps 2 and 3 above.

If you want to switch between multiple profiles you can use gh profile switch [NAME]

That's better, but I promised you we were going to be able to use different profiles based on the current directory. In order to achieve it, follow these steps:

Install and setup direnv following their official tutorial: https://direnv.net/docs/installation.html
Whenever you want to set a profile for the current repo, use the -l option:
gh profile switch [NAME] -l

Done. Now whenever you use your terminal on the current directory, is going to be using that specific github profile. No need to keep switching anymore!

Stop overcomplicating your React components

Guilherme Samuel — Tue, 23 Feb 2021 02:07:19 +0000

For a considerable time, I worked developing components that had unnecessary props and logic. Today I want to show you how to develop flexible and maintainable components so you don’t keep doing the same mistakes I did.

The problem

Take this Card as an example, what’s wrong with this?

A lot of props, making the API complex

There’s a lot of props. So many that probably someone using this component will never use some of it.

It’s hard to maintain

For every new feature, another prop has to be passed and more logic has to be done.

Not flexible

Imagine if you want to change the position of any component, again you have to include one more prop and add more logic. You basically has to create a prop for every use case.

The solution is…

Composition. Breaking your components into multiple elements will make it way simpler.

It's flexible, customizable and maintainable

Want to change the order to have a subhead after the thumbnail? Change it. Need to customize any component inside card? Just insert a className and style it. The thing is: here you build your component the way you want, not the way the API forced you to.

When having that much of props is actually a good option

1. You’re building a component to display some fetched data.

Spreading a object will make it's keys and values to be used as props. It's practical.

2. You don’t need any flexibility or customization

There’s no significant advantage to take from composition, so it’s fine to just use props in this situation.

Conclusion

When you need flexibility in your components, take advantage of component composition. Break your component into multiple components and it will be a lot simpler to work with.