Pushing Pixels

Atomic whatnots and styled who what now?
⁠As part of my frontend developer programme, we were recently tasked with creating a menu application for a restaurant-type business, both from the user's perspective and also an employer's perspective. This project was the perfect testing ground for implementing Atomic Design and Styled Components.

Although there were no connection to databases at the moment, some requirements were in place; it had to use Zustand and a connection to a certain API that my teacher set up. All well and good. Apart from that we were free to do as we pleased.

⁠⁠Is this familiar to you?
You start a project, set up your css styling, and as the project grows so does your css. Eventually you decide you break it up into smaller parts, and have several css files. Suddenly, you end up with an element that doesn't do what it's supposed to do according to your css code; it is getting overwritten by something somewhere else. But now your projects have 2 css files and one of them is 400 lines long.
Ouch!

Styled Components
Just before this project I learned about Styled Components (SC), and figured this was a golden opportunity to try it out in a bigger project. Briefly explained, a styled component is a React component that allows you to embed CSS code directly within the component file. Imagine you're writing a letter and you get to design the letter's look right in the margins as you go.

That's sort of what it’s like using Styled Components. It keeps everything neat and together instead of having a separate page just for the letter's design.
This approach keeps your styling organized and straightforward.

Atomic Design
I also very recently learned about Atomic Design (AD) and ⁠as curious as I am, I wanted to learn this design system. Atomic Design organizes projects in a bottom-up structure:

Think of Atomic Design like organizing your kitchen.
You start with arranging your spices and utensils (atoms), then you set up your drawers and shelves (molecules), and finally, you have the whole kitchen setup (organisms). It’s all about building from the smallest part to the whole system.

The larger components are built from smaller ones, and these smaller components are themselves composed of individual elements.

I thought that AD and SC would work well together.
I asked my other teammates and they agreed, so let's try it!

⁠Here's what I learned:
In retrospect, for me at the least, when setting up a project with AD there are some pitfalls to watch out for. If you don't plan accordingly, or if plans change, things can get messy fast. Couple this with SC, and things can get real messy. With a proper structure however, it makes total sense (to me).

But the thing about SC is that you can end up repeating a bunch of code, and your once-clean-component suddenly is a 200 line component, where most things are just a styled div.

For example, consider this code:

<ItemLine>
  <span>Text</span>
</ItemLine>

Seems simple enough, no? This is a SC with a span inside it.
Here's the corresponding CSS:

The line:

width: 100%;
text-align: center;
border-bottom: 1px solid rgb(221, 206, 205);
line-height: 0.05em;
font-size: var(--font-med-smaller);

..and the span:

padding: 0 14px;
background-color: var(--main-color);

So when making a SC as above you make a component, declare what type of thing it is, and then you style it and you do all that in the same jsx file, like so:

Make the SC, which in this case is a <p> tag, denoted by 'styled.p' where the 'p' indicate what tag it is referring to.

You could do styled.div, or styled.h2 or whatever; you get the idea.

const ItemLine = styled.p`
  width: 100%;
  text-align: center;
  border-bottom: 1px solid rgb(221, 206, 205);
  line-height: 0.05em;
  font-size: var(--font-med-smaller);
  span {
      padding: 0 14px;
  background-color: var(--main-color);
  }
`;

So now we have a SC. Great. Let's use it like so:

<ItemLine>
⁠  <span>Langos</span>
⁠</ItemLine>

(yes, we made a langos food truck restaurant, hence the word 'Langos' in the span).

Whew, that was way too easy. I like this SC debacle I think.

...but here's the kicker; Some of the components I made eventually grew into monsters and it's nothing I am proud of.

(to my teammates; this is not calling anyone out, you were all fantastic!)

⁠Thoughts
Without proper planning, your component can quickly end up looking like this (which is actual code from our restaurant menu, btw):

const StyledFooterSection = styled.footer`
  width: 100%;
  background-color: var(--compliment-color);
  background-image: url(${footerSectionBg});
  background-repeat: no-repeat;box-sixing: 
  border-box;
  padding: 0 20px;
`;

const Subtitle = styled.h2`
  color: var(--secondary-color);
  padding: 1rem;
  font-size: var(--font-med-small);
  line-height: 1;
`;

const RandomFact = styled.h3`
  color: var(--secondary-color);
  padding: 1rem;
  font-size: var(--font-med-smaller);
  line-height: 1.15;
  letter-spacing: 1px;
  padding-top: 150px;
  box-sizing: border-box;
  span {
    font-size: 2em;
  }
  letter-spacing: var(--letter-spacing-big);
`;

const FooterInformationContainer = styled.div`
  display: flex;
  flex-direction: row;
  justify-content: space-between;
  color: var(--secondary-color);
  padding: 1rem;
  font-size: var(--font-med-smaller);
  letter-spacing: var(--letter-spacing-med);
`;
const LeftContainer = styled.div``;
const RightContainer = styled.div``;

export default function FooterSection() {
  const randomFact = facts[Math.floor(Math.random() * facts.length)];
    const factString = randomFact.fact;
      return (
	<StyledFooterSection>
	  <RandomFact>
	    <span>Visste du att?</span> <br />
	      {factString}
	  </RandomFact>
          <Subtitle></Subtitle>
	  <FooterInformationContainer>
	    <LeftContainer>Adress: mellan första och tredje lång</LeftContainer>
	    <RightContainer>andra-langos@gmail.com</RightContainer>
	  </FooterInformationContainer>
        </StyledFooterSection>
      );
}

.., and I mean, it is readable, but consider that this is one component, one organism in the AD design pattern. It houses a bunch of SC's as containers in order to structure the rendering properly.
You should see the component I did for the dropdown. I cry when I look at it, because it grew into something terrible as new things popped up, mainly because of the previously mentioned lack of proper planning.

Me: destroyer of worlds
To make things worse and probably as a response to this lack of proper planning on my part, when creating this component, I even mixed SC with inline styling as the component grew.
..because.. well. because.
As I said nothing I am proud of haha!
I digress.

Technically this footer above is just one .jsx component, but because of the nesting of SC's it looks like a complicated organism instead. It should probably even be a molecule in the AD pattern I think, but not sure, and there are no hard rules.

But as you can see, even with just a few SC's, things can escalate quickly.

Is this the fault of our lack of planning, or our lack of understanding how to implement and use these two systems properly?
Could very well be so. Most likely so, since we were all new to these systems, and I'm sure we will learn how to work with it more in the future.

If it works, it works
So, that was a little blurb about SC. Now let's talk AD, because to me this is where it gets interesting. I love this design system. Not gonna lie though, it can be frustrating to work with when you need to lift states and send props and whatnots at times, but holy crap when it works it's amazing.

For example, we had a rendering component. The entire purpose of this component was to take some props, and pass them on to the sub-components of this rendering component.

⁠This means two things:
We can reuse it whenever we need to render a menu item.
If we need to change any of the items it holds, such as changing how the images looks perhaps, or the order of the price, title, ingredients etc, we go into the subcomponents and do that; we don't need to barely touch that component at all.
This makes sense, this is essentially how react components work anyways, they render stuff at the end.

So what?

I hear you thinking behind your screen there.

A react component is the same, what is the benefit really? I can also change the styling of a react component, what are you even talking about?

you think while you look back at your Inputform.jsx component and feel proud at how easily read it is.

The really strong point with atomic design is that once you structure your project with it you always know that a button is always an atom, and changing that thing will propagate throughout the entire project in one go, and you have a small file to work with. No need to touch anything else.

Sooooo...
That means your Inputform.jsx we just talked about suddenly is modular and you can change it, change the things inside it while you stay consistent through out your entire app.
Example:

That button row you have and that you re-use? You want to change the flex and have the entire app update, say from a media query, but you also have variations of this row everywhere?
What do you do?

Perhaps you feel that you need to zombie build out by adding different classes and use sub-selectors in CSS and whatnots to solve this? How about just making duplicates of the buttons, that's an ok approach though, right?

Oh, I know, let’s just wrap it in a div and then use CSS inline styling instead!

...Ah, but there's so many of them and what if we need to update the style at some point in the future?
Shit…
This could get frustrating!

*pause for dramatic effect*

K.I.S.S - Keep It Simple, Stupid.
Here's what you do: Make the button row into a Styled Component (SC). Wherever you're rendering it where you need to have a variation, wrap the row into another SC, and style it as you please.

Then you go to the main button row, set up a media query and boom!, the entire app updates with one small change, but they all keep their individual stylings. This way, you can change the main styling easily.
Surely, this can be done with CSS also, but consider what we talked about earlier; what if your app has 50 button rows with 30 different variations, and the entire APP had 150 UI elements?

Enjoy diving through that CSS; I wouldn't if I valued my sanity.

The caveat with SC is then; there could be issues with over-riding and/or conflicting CSS from.. uh.. well. actual style sheets.

Knowing full well that this is the internet and nobody probably actually read the link provided in the beginning (no judgment, I am the same mostly!) because you first want to know if it is interesting and useful or not: this is how it works, sort of:

The bigger the component is, and the more sub-elements it contains, the bigger size it gets in this design universe.

Atoms are small; a button, a slider perhaps, an input. ⁠
Molecules are slightly bigger, containing atoms.
Organisms contains several molecules.

Looking at it like this you can clearly see the benefit of this: change something at the atomic level and it propagates all the way up to the organism.

My thoughts on these systems is simply this:

If planned properly and considered when implementing, these two systems together are simply made for each other. They marry perfectly.

I've been watching some tutorials about webRTC on the famous video platform on the internet we all know and love, and figured I wanted to make a little video app. Following along with Traversity Media I managed to get my ICE clients and all that jazz setup, but for some reason my connection fails and I have no idea why. It doesn't matter, because this was the interesting part anyways, and now I (somewhat) understand how this works and I am so happy about that, because I can see about a quadrillion uses for this already.

I have some ideas as to why connection fails, but not entirely sure yet, but as long as the other stuff works I am confident that I can figure out how to not get stuck in the checking phase of the connection. ⁠The app works perfectly with several browsers, and even when joining on mobile, but not so much with someone else outside of my network. I do get the candidates, streams are being setup and everything so everything works except the connection.

For those of you who doesn't know, that link above is a like 4 hour full course in case you wanna go through it all, or just do the first part as I did to get an understanding on how it works in the back. There's also this video by JavaScript Mastery, which also happens to be one of my favourite channels. There's also a repo linked in the description, but didn't wanna jump straight to that without understanding the code I was looking at, because that's not how you learn.

And now that I understand how it actually works (again, somewhat,) I can revisit the mighty Fireship and *finally* look at this 100 second webRTC thing and understand what the hell is going on haha!

So, I just stumbled upon a magic video person called Franks Laboratory, where he goes deep into creative coding with just vanilla javascript, and uh, I love it.
Here's some things I did:

So this is basically just the same code but with a very few minor tweaks.
Pretty damn cool. He explains the code very well, and although some of the math is above me, I do understand how it works, as you normally wouldn't with using a library, which is awesome.
I've had so much fun tweaking this and figuring out extra things to do with it!

So, today when randomly perusing the internet's most famous video platform, I stumbled upon Taipy, an open source Python library designed to basically supercharge your development.

Now, I have barely touched Python and I have some gripes with it, but honestly, I saw this video introduction to their GUI and I instantly want to learn it. ⁠
It's.. ridiculously fast to get basic stuff up and running, really..
I will link the video below, but first let's do some stuff with it. ⁠

It comes with their own components builtin, right?
So, let's say you want to make a slider on a page, you simply do it like this:
* Import the GUI.
* Define the page.
* Make a slider. ⁠

So, here's ⁠a page, in two(!) lines of code:

from taipy.gui import Gui ⁠
Gui(page="This is my home page").run(dark_mode=False) 

Here's Groq explaining the syntax for you:

In this example, we first import the Gui class from the taipy.gui module. We then create a Gui object and specify the page argument to set the home page of the application. Finally, we call the run method to start the application, passing the dark_mode argument to specify whether to use dark mode or not.
Note that the argument names in Taipy are written in snake_case, so it is dark_mode instead of dark-mode. ⁠ ⁠

⁠Ok!
So now we have a home page that says "This is my homepage".
Great. ⁠
So now, let's add a slider from their library.
Ok..

<|slider|> 

Yeah. It was that easy.
Pretty amazing, right? ⁠

So let's say that we want to assign a value to this slider instead. We define the variable and then assign it to the slider:

value = 100 ⁠ <|{value}slider|> 

Then we display it like so:

<{value}> 

Whew, that took about.. 3 seconds? ⁠
Don't worry if you don't understand this syntax, Groq has you covered again:⁠

In this example, the <|...|> syntax creates a markdown widget that displays the value of the value variable. This will render the current value of the value variable in the markdown cell.

Here's a list of their visual elements:
https://docs.taipy.io/en/release-2.4/manuals/gui/viselements/

Do note that this is made for both backend and frontend, so there's plenty more stuff to this, but that introduction is just.. uh. How fast can you go, really? ⁠

.. and finally, ⁠here's the video: ⁠https://www.youtube.com/watch?v=OpHAncCb8Zo

So as I am developing this blog further, I decided to try my way at doing some tag-implementation.
The basic idea is this: You have tags that you store somewhere, and then you display them as part of your frontend, and make them clickable. When clicked (ie, when 'active') you change some property (say color) to let the user know they are active, and then you filter your posts to only display these tags.

So, to do this we can use state in React. Conveniently it's called useState, so we can import it at the top like so:

import { useState } from 'react';

⁠In my card component that renders my cards, I filter my selected tags:

const [selectedTags, setSelectedTags] = useState([]);

	const toggleTag = (tagItem) => {
		if (selectedTags.includes(tagItem)) {
			setSelectedTags(selectedTags.filter((tag) => tag !== tagItem));
		} else {
			setSelectedTags([...selectedTags, tagItem]);
		}
		onTagClick(tagItem);
	};

and then in my return, I can do this (styles.tag and styles.active are imported from a module.css):

{tag.map((tagItem, index) => (
	<span
	key={index}
	className={`${styles.tag} ${selectedTags.includes(tagItem) ? styles.active : ''}`}
	onClick={() => toggleTag(tagItem)}
	>
	{tagItem}
	</span>
))}

and then in my container where I want my card, I do this:

<section className={styles.posts}>
	<div className={styles.container}>
	{filteredPosts.map((post) => (
		<BlogCard
		key={post.id}
		title={post.title}
		datePublished={post.datePublished}
		slug={post.slug}
		tag={post.tag}
		content={post.content.html}
		onTagClick={setSelectedTag}
		/>
	))}
	</div>
</section>

⁠Sure, it only filters on the on-state right now, but that's the basics of it!