
Yesterday (01/05/2022) we made our first reunion, sadly with only two of us personally ([Renato](/team/renato) and [Bruno](/team/bruno)) and one via Google Meet. But even in this situation, we did a lot of progress.

-   We choose a font: Robot for the body of every text (Maybe try Open Sans in the future).
-   We tried some palette colors 
-   Improve the overall CSS structure with new variables

# Choosing Fonts
To choose the font we made some kind of display of the possible options. Between the options was:

- Mukto
- Inconsolata
- Open Sans
- Roboto
- Nunito

We ended up with Roboto, just because the time was running out. Maybe I will test some Open Sans in the future


# Trying Palettes

It was a lot of fun and we are excited to improve each time more this website and write new and improved articles here.

  
Between the pallets tested we have these:

![mouse-palette](mouse-palette.webp)

---

![granito-palette](granito-palette.webp)

---

![baleia-palette](baleia-palette.webp)

---

![cimento-palette](cimento-palette.webp)

----

I liked the gray one. But will try nome others in the future, thus it's nothing defined yet. Maybe a bluer grey. 

  

To improve the palette swap I created many variables to centralize the styles of the website. In the future, I want to make a Dark Theme as well, but to do this will need to make some changes again. 

  

And to document the moment, we decided to shoot some photos *(and I made some effects by hand)*:

![painted-1](painted-us.webp)

Reunion 0.1


In this post, which is kind of a tutorial, I will show you how I [Renato](/team/renato) implemented this blog's dark theme system, how to implement it on your own with CSS only. How CSS variables work and why use CSS only for it instead of a simples package.

# Understanding CSS Variables
Like in any real programming language you can declare variables and use them, even not been a programming language you can declare variables in CSS as well. 

A CSS variable is declared using double-dash `--name` plus a semicoma and then the value of this variable:  `--example: blue;`.

These variables are created inside scopes and can only be used for those inside that scope. So if you create your variable in a `.blog-page{}` scope, it will only be available for its children.

Using a CSS variable is like calling a function `var()` with the parameter being the name of your variable. 

Look this example of the scope and use of a variable:
```css
.cool-page{
	--best-color: #382F60
}
.cool-page h1{
	color: var(--best-color)
}

.another-page h1{
	color: var(--best-color)
}
```

In the first `h1` use (*.cool-page h1*) the variable will work perfectly. But in the second one (*.another-page h1*) it will not work. Because the variable is only declared in the `.cool-page` scope.

CSS variables can be anything:
- Colors;
- Sizes;
- Fonts;
- Borders;
- Shadow;

And any kind of CSS value that can be used in CSS can be stored in variables to be used later.

When I started this website I created all my variables in the `:root` class, so every other element could use it (you can use HTML or body tag instead as well).

Another thing to notice is that you can **overwrite** variable values in another CSS element, so if you declare `--cool-color` in the *root* element, you can overwrite it inside of *body* and change the value for all those which are inside of it.

Those variables are very useful if you want to test palettes, change fonts easily, etc. So even if you are not going to a *dark-theme* implementation, I recommend you to use CSS variables.

# Making Dark Theme With CSS Only
So, you can define and use variables in all your code. If you define it all in the `:root` you can use it anywhere. Changing only one variable you will change the value for all the elements that use it.

The dark theme with CSS only is based on this idea:

> Build all your styles with variables, then, when you change the theme, change the value of all the variables.

To change these variables we can define the variables in the `body{}` element. Define your variables there and create a `body.dark{}` element as well and overwrite all the variables there:

```css
body{
	--cool-color: #382F60;
	--font-color: #2d2d2d;
}
body.dark-theme{
	--cool-color: black;
	--font-color: white;
}
```

The idea is to change the *body* class depending on the theme that you want to use.

---
If you declare all your variables and overwrite them in the `body.dark` you can already test it by adding a *class* to the *body* in your browser.

# Changing Themes Inside Next.JS
There are problems changing CSS inside *Next-JS* thus it's a server-side rendering, but it's still possible.

But first a context: I created a theme switcher on my page, and the code that I will explain now is inside this component.

---
Thus we are using Next-JS, we need to set some *useState* to manage the state of the theme. Then we can create a simple function to change the theme depending on the theme that is already set.

```jsx
 const [theme, setTheme] = useState('light-theme');

 const switchTheme = () => {
	 if(theme === 'dark-theme'){
		 setTheme('light-theme');
		 return;
	 }
	 else{
	 	setTheme('dark-theme');
	 }
 }
```

But until here we are just saving this value and not applying it in the class of the body. To do so, we will need a `useEffect()`. This *useEffect* has two reasons to be here.

The first is to let us know if the website is loaded, thus this function only executes when the website finishes the pre-load.

And the second is to know if the code is being executed in the server (during the server rendering) or during the client access.  That's why we need to have a **loaded** state. We will set this **loaded state** as *true* if the  `useEffect` execute and then we will pass to the *body* the class of the theme that we are at.

```js
 const [loaded, setLoaded] = useState(false);


 useEffect(() => {  // if we are at the client side,
	 setLoaded(true); //  set loaded as true
	 document.body.className = theme; // and add the class to the body
 });

```

If you don't use the `useEffect`, the framework might don't build the project or even don't run the page.

---
Now, when constructing your *theme switcher* you need to use this *load* variable to check if is everything allright to render (if we are at the client and if all the page has already been rendered):

```tsx
 return(
	 <div onClick={() => switchTheme()}>
		 {
			 loaded?
				[themeSwitcher]
			 : <></>
		 }
	 </div>
 )
 ```

# No Colors on Loading Problem
Thus, the code to decide the theme that is active only executes when the page loads. You may have a problem with no defined colors when your website starts to load (before the "choose theme" function be executed). To fix that you have two options:

## Option 1
Instead of creating two classes for the body `.dark-theme` and `.light-theme` you can create only one and add or remove it on the *change theme* code, instead of changing from one to another. In this way, the no-class colors will be loaded instantly.

## Option 2
You can define *general-colors* (that don't change) and main colors in the `:root` element. In this way, these *general-colors* will be loaded on start and overwritten if needed after the *change theme* code execute. This helps if you want to add more themes in the future and it's the option that I choose, mainly for readability.

```css
:root{
	--header-color: blue;
}
body.light-theme{
	/*just uses the defined in the :root*/
}
body.dark-theme{
	--header-color: black;
	/*overwrite the root color after the loading*/
}
```


# Other Methods
Of course, you could  use a package, but personally I always rather do it myself instead. In this way, you learn more about your tools and how things work.

Anyways, it's that. Any questions or advice you can send me on my [Twitter](https://twitter.com/nerat0). I always post some updates about this blog there as well. See ya!


The Easiest Way to Achieve Dark-Theme


All the posts of this website are written in `.md` files, which is a much much better way to write content without losing your mind with HTML opening and closing tags. Websites such as Medium, LinkedIn, and GitHub use this Markation language to save and write their posts and **READMEs**. So nothing better to use it as well. The Mark-Down also provides an easy way to write for a non-programmer person, so it's very good for our future teammates as well. Thus this is a static website all the mark-down translation happens in the build time, instead of in the "consuming" time. That is, this work is done by the server when a new version of the website comes out, and not by you, the lovely user. 

# Configuring the Mark-Down file
The `.md` file is configured by a header, where you can declare variables to use later, those variables can be anything, lists, numbers, string, etc. The configuration of this post looks something like this:

```yaml
---
title: 'The Way We Do MarkDown Transcriptions'
date: '09/02/2022'
author: 'renato'
cover_image: 'cover'
excerpt: "Explaining how our .md to HTML works and the new features I just implement"
categories: [BLOG, DESIGN, PROGRAMMING, NEXTJS]
---
```

The title, date, excerpt are very auto-explanation. The author is just a key to getting its info later and the categories the same (the upper case is just something for visualization). The cover image is very simples as well, is the name of the image that will be used as a cover. You can read more about the way we deal with images in [this post about it](/blog/default-images-and-our-images-architecture). 

After this header comes to the post itself. We use [grey-matter](https://www.npmjs.com/package/grey-matter) to separate the content and the header variables. Then we use a `createPost()` function to get the detailed information of the author and each category.

# The Transcription It Self 
In the first versions of this website, we used to use [markdown-it](https://www.npmjs.com/package/markdown-it) to transform `.md` files into HTML. But MarkDown-it has some problems, that is, fewer features.  MarkDown-it doesn't provide a replacement of translated HTML (so you cant use code highlight in code block). This package doesn't provide many other `.md` translation like
- check-boxes
- tables
- footer notes

Now, for the other side, [react-markdown](https://github.com/remarkjs/react-markdown) provides all of it and much more. Thus react-markdown uses remark as an API and it has some kind of modular separation, it provides the addition of plugins, such as remark and rehype plugins. React-markdown also provides a way to replace the HTML translated with functions. So if I want to change every link that has my name to a golden and shines name, I actually can.

# Amazing Possibilities
Using this kind of replacement I was able to replace every code block with a Prism Syntax Highlighter React element that can provide us with those beautiful code blocks. Or for example the replacement of every image by a zoomable image element that I created. Or even the stylization of our check-boxes. There are many other things to replace yet, and the code of it is very ugly but it is stills very useful in this case. 

I also realized some days ago this plugin thing of the package and added some of those to our project. Like tables and footer-notes. I still need to test it on smartphones, etc but it is already working[^1] . The go-to footer not is working fine, but the come back doesn't for no reason. Maybe I implemented something wrong, but it should work. The tables thing was something that I was missing up for future posts, and now I don't.

We still using grey-matter for the post card, thus the post just needs simple transcription.

---

Now, here is a table example to test it out:

Feature | status
-------| ------
Tables | done
Footer-notes | done
Hover-teammate-name | stylizing
zoomable-images | cool but not perfect
Dark-theme | don't have any idea
News-letter | what? how?
Writer/post info | Designing

# More Slylish Quotes
Another thing that I added thus those ones, was a property style for the `<blockquote>` component. That goes like this:

>Now I've heard there was a secret chord
That David played, and it pleased the Lord
But you don't really care for music, do you?

I'm not sure about this grey background, but I think it's ok!

# RSS Feeds
I still messing around with this, but anyways. Now we have an RSS feed generator script. So you can get its link and paste it into any Feed reader to have these posts in your App. It still with some images and date problems, but it works, and it's very cool.

* [x] RSS feeds and links component

Also created a simple component to hold these links at the end of each post and blog page. as you can see here ⬇️ 

[^1]: See?



The Way We Do MarkDown Transcriptions




I just finished the implementation of the default images that appear on posts that don't have a cover. It was something that wants to implement because those old flat colors were very ugly.

![posts-exemple](posts-exemple.webp)
 
The logic is to have those default images saved locally and just change the `cover_image` URL to a default one when the post doesn't have a `cover_image` defined. We can choose default cover images as well using **number**. 

# How To make Good-Looking Cover Images
Yes! Those images are pretty cool. I found an online generator of section-transition images to be used in websites, but the images are so cool that can be used anywhere (you can check out the [generator here](https://app.haikei.app/)).

![generator-site](generator-site.webp)

So I changed the colors and play a little bit with the configuration in some generation options and ended up with this ones:

![default-image-1](default-image-1.webp)

---

![default-image-2](default-image-2.webp)

---

![default-image-3](default-image-3.webp)

---

![default-image-4](default-image-4.webp)

---

# How The System Works

The system is very simple. We just verify if the `cover_image` variable is a valid image, or if it's of the type *Number*. If the image isn't valid or is a number we choose one of the four default images and use its URL instead. Let's see: 

# How We Store Posts Images

Before understanding how the default images work, you need to understand how we store our post-images in the first place. All the website logic, programming, design was made by me ([Renato](/team/renato)). And I do not have sure that this is the best architecture option to store posts images, but is the one that most fits my case. Maybe in the future, it changes (I hope not). But for now, it is what it is.

We have a **posts** folder in the root directory. inside this folder, there is every single post written in a `.md` format. The name of each post is its name in lower keys separated by a dash/trace '-'. For example, this post file name is `default-images-and-our-images-architecture`. This name serves as **slug**/ID for the post. Now inside our `public/images` folder, we have another **posts** folder, this one has one folder for each post written, the name of those subfolders are the same as the post that it belongs to. Inside those subfolders, we store all the images used in each post. 

![folder-organization](folder-organization.webp)

I think this is a good approach to storing multiple blog images. It would be a terrible solution to just throw every single image inside the same folder, and not separate it by post. How would you find an old image inside it? How would you manage thousands and thousands of images when the website grows?

Another thing is the dash/trace ('-') nomenclature chosen. I know that CammelCase is good when you are coding, but it's good when you are using the code font, and not a file / OS font. It's terrible to read it in almost all common fonts. So the dash is a good choice. And why not an underscore ('_')? To tell the truth, is simpler than it looks: it takes more work to type. Instead of using `shift + '-'` to write every simple space in the word, just use the dash. In the end, it's like a space-bar on the top of the keyboard :)

---

In this way, we have an organized way to store all our images knowing where each one is always.


# And The Default Images?

Each *default image* is saved in a `default-images` folder, inside `images/posts` as a number (1 to 4) in `webp` format (because of performance). 

Our "choose image function" is called `getCoverImage()`.

It receives a **slug** And a **image_name**. This *image_name* is set in the header of the `.md` file. It just contains the name of the image that will be on the cover. Why just the name? Because we already have the **slug** of the post (that is, the *name* of the post folder where all the images are). So we can get any image just using `images/posts/{slug}/{image_name}.webp`.

> I just realized that I can use this same strategy to get every single image inside the post. So instead of declaring it `images/posts/default-images-and-how-we-store-images/image-name.webp` we can just use `ìmages-name.webp` for now on!

Anyway, The first thing we do in our `getCoverImage()` is to create the return variable and check if the image exists or if the type of the variable is a number. 

```js
var coverImage;

if(!isImageCoverValid(slug, image_name) || typeof(image_name) === "number"){
	 var defaultImageIndex = image_name || Math.floor(Math.random() * 4) + 1;
	 coverImage = `/images/posts/default-images/${defaultImageIndex}.webp`;
	 return coverImage;
}
```

if it's a number, that means that the author wants to choose one of the default images. So just set the `defaultImageIndex` as this number. But if it is not valid (is null or starts with "HTTP" or is not in the post folder) choose a random number to get a random default image in the next line. So the cover image source string is made, and the value returned to the post.cover_image.

Now, if the image is valid, we just create the source path using the variables (slug and image_name) and return it:

```js
coverImage = `/images/posts/${slug}/${image_name}.webp`; 
return coverImage;
```

Look how the **isImageCoverValid()** works inside:

```js
const isImageCoverValid = (slug: string, image_name: any) => {
	const isImageTextValid: boolean = (
		typeof(image_name) === "string" && 
		!image_name.toString.startsWith('https')
	)

	if(image_name === null || !isImageTextValid ){
		return false;
	}

	var imageExistInFolder = false; 
	const images: string[] = readdirSync(join(`public/images/posts/${slug}`));

	for(let image of images) {
		 if(image.replace('.webp', '') === image_name){
			 imageExistInFolder = true;
			 break;
		 }
	}

	return imageExistInFolder;
}
```

We check if is a text and if has *HTTP* (we do not allow other cloud images). If is not null and is a valid text we create a variable `imageExistInFolder` and start to search for the image inside the post folder. If the image appears we *break* the loop and return that the image is valid. So doesn't need to use a default image. 


certainly

Of course, there is room for improvement all over it, (like creating the images with Python instead of using HTML tag to make the post date in the middle). But for now, it's this.

Anyways, this was the best post written until now. So I hope you enjoy it!

Reunion 0.1

Sumário

Choosing Fonts

Trying Palettes

Recomendations

The Easiest Way to Achieve Dark-Theme

The Way We Do MarkDown Transcriptions

Default Images And Our Images Architecture