[refactor] Improve current implementation of atoms

[open-sauced]

[refactor] Improve current implementation of atoms

[chadstewart]

So I actually deleted the strong text component in the PR related to this issue. Honestly, it was a quick and dirty way of fixing an issue I had with the text component when I wasn't as knowledgeable about supabase ui.

So we could build our own ui components but honestly, that'd be a lot more work than it really needs to be and the only thing we really get out of it is a bit more control of each ui component. So for things like text and buttons which are relatively simple to build, I can see why it seems like it makes no sense. But as soon as we get into complicated components, trying to build them out ourselves will take up a massive amount of time that we don't have. Why not leverage something where these components are already built and tweak them to our needs?

I think the biggest issue with some of the components we're using now is that we're still relatively new to Tailwind and I'd have no problem applying styles to elements buried in a component but I haven't figured out how to do that with Tailwind yet. Honestly though, I'd much rather hack at a ui library and just make it do what I want rather than build the component myself. There's a lot of states that we may need that we could easily miss trying to build it out ourselves and all of that is just not a great use of the limited time we have.

[pixelsbyeryc]

That makes perfect sense... Thanks for the thorough explanation, Chad!

We can have a chat next week if you want, to think of ways we can use Tailwind on elements buried in components.

It might take some Tailwind hacking, but you're right, it'll be faster than creating our own components 🙏

[pixelsbyeryc]

As I was creating components, I found passing down props to Next or Supabase components were a bit annoying... Two things I can mention from the Text component:

1. I'd prefer not to have the <StrongText> component
2. It feels like we're hacking Supabase/Next components, when we could create our own with HTML elements.

1. I'd prefer not to have StrongText component

I'm a bit biased towards not having a "strong text" component mainly because we'll be using more than 2 font-weights across the UI... Eg: Scanning though this GitHub page, I found at least 3 font-weights: 400, 500, and 600.

We can define the weight as a prop in the component, like we define levels (1 = h1, 2 = h2, ...) in <Title>.

It feels like we're hacking Supabase/Next components, when we could create our own with HTML elements.

Unfortunately, they don't allow anyone to pass props into the atom and have that prop passed down to the supabase components.

Ideally, the component should allow the props passed into the wrapper to be passed down to the supabase component.

Do we really need to create a Text component built on top of the Supabase Text component? Wouldn't we be better off creating our own simple component? It feels like we're trying to hack their component for our use...

The <Image> component (unrelated to this issue, but worth mentioning)

Next wraps the <img> element with 2 levels of <span>s. It probably has its reasons to do this, but I tried adding a simple outline or border to the <Image> element, and it wouldn't work. Because one of the <span> that wraps it had overflow:hidden;.

My solution was to create another <span> that I could control, and add a border to it.

Things like these make me wonder whether creating our own components would be easier and simpler than using some of these components from Next or Supabase... I don't have enough experience with React to know better, though. 😳

[chadstewart]

Sure, that's no problem at all. Let me know when you want to chat.

[github-actions]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀