linkedin.svg

LinkedIn

instagram (1).svg

Instagram

facebook.svg

Facebook

twitter.svg

Twitter

github (1).svg

GitHub

large_adam-2022.jpg

medium_adam-2022.jpg

small_adam-2022.jpg

thumbnail_adam-2022.jpg

adam-2022.jpg

TIL means Today I Learned. And that's what this series/category is all about - short and quick articles about everyday problems that I have dealt with, and along solving them, I came up to an interesting solution that you might also implement one day.

**Ever had a headache because of the number of branches you have on your repo locally?** If so - I have something for you.

Working in a git project with some team members, and lots of tasks - you don't have any other way, than to work on a separate branch for each task. This is pretty useful, and GitHub also deals with it quite nice by deleting the merged branches... but that doesn't happen on your local repository. Also, git branches are *light* - they just point to a specific commit in the repo's history. And commits are also light. So having lots of branches won't cause huge performance issues, and thus - we don't remember to always delete the branch after we finish working on it - because it's not a big deal to keep it!

Unless it is. Sometimes you have to switch between branches, go to a branch that you just pushed, because you started working on an another task, and then you have to go back because you've got to make some changes from the code review. And that's the point where a problem araises - you don't remember the name of the branch... and you have to crawl through all the branches you have locally (assuming you're lazy enough to not just switch to the browser and check the branch on PR...). So this argumentation may not convince you. But still, even though you don't have problems with switching between branches, wouldn't it be nicer if you local repository was clean, and you had only, let's say, 5 branches? In my opinion - it would.

### So if you're a person like me, you'll love this shell&nbsp;snippet!

```bash
git branch | grep -v "[branches]" | xargs git branch -D
```
_Now just replace the `[branches]` with the **names of your branches you want to have preserved** divided by _`\|`_ (for example _`master\|develop`_) and... voilà_


### Or you can go even further, and create a short bash script like&nbsp;this!

```bash
#!/bin/bash

BRANCHES=""

for branch in "$@"
do
    if [ "$BRANCHES" = "" ];
    then
        BRANCHES="$branch";
    else
        BRANCHES="$BRANCHES\\|$branch";
    fi
done

git branch | grep -v "$BRANCHES" | xargs git branch -D
```

I saved it in a file called `gbc` - Git Branch Cleanup - and I can use it like this (if I want to for example remove all the branches except master and develop): `gbc master develop`.



<p style={{ fontSize: "0.8rem", lineHeight: 1.2 }}>

_I do not take any responsibility for accidentally removed branches, broken repo histories and other f\*ckups. If some wrong things happen - I recommend you to check out the tips on https://ohshitgit.com/_

</p>

Ever had a headache because of the number of branches you have on your repo locally? If so, take advantage of the tips from this post :)

TIL: Cleaning your Git repository by removing the unused branches

When dealing with bigger amounts of data that you have to somehow transform (for example map over) in Elixir, you might encounter a problem of running out of memory or losing the performance that Phoenix and Elixir can provide.

What they can provide though, are **Streams**. Elixir Streams allow you to build a pipeline of operations, and are really beneficial when working with larger amounts of data - what they do, is they chunk the set of data you have, and do the transforms (like maps, filters, etc.) on demand, in those chunks, which allows to **save a lot of memory**, by not loading the whole set at once, rather “streaming” the data one after another. Simply speaking - Streams are basically “lazy” enumerables.

This concept would work perfectly when working with large sets of entities from the database, wouldn’t it? That’s what also Ecto’s developers thought, and thanks to them - we have the Ecto’s `Repo.stream/1`.

## Example

Let’s take a look at a real example of how a simplified code for preparing and rendering a sitemap, with the help of Phoenix, would look without, and then with the Ecto’s Stream:

```elixir
def fetch(conn, _params) do
  render(conn, "sitemap.xml",
    sitemap_items: get_sitemap_paths(),
    host: "https://appunite.com"
  )
end

def get_sitemap_paths do
  sitemap_profiles() ++ sitemap_posts()
end

defp sitemap_profiles do
  from(u in User, where: is_nil(u.deleted_at))
  |> Repo.all()
  |> Enum.map(fn profile ->
    %SitemapUrl{
      url: "/profiles/#{profile.slug}",
      lastmod: profile.updated_at
    }
  end)
end

defp sitemap_posts do
  from(p in Posts,
    where: p.private == false and is_nil(p.deleted_at)
  )
  |> Repo.all()
  |> Enum.map(fn post ->
    %SitemapUrl{
      url: "/posts/#{post.slug}",
      lastmod: post.updated_at
    }
  end)
end
```

and then with the `Repo.Stream/1` 

```elixir
def fetch(conn, _params) do
  {:ok, conn} =
    Repo.transaction(fn ->
      render(conn, "sitemap.xml",
        sitemap_items: get_sitemap_paths(),
        host: "https://appunite.com"
      )
    end)

  conn
end

def get_sitemap_paths do
  Stream.concat(sitemap_profiles(), sitemap_posts())
end

defp sitemap_profiles do
  from(u in User, where: is_nil(u.deleted_at))
  |> Repo.stream()
  |> Stream.map(fn profile ->
    %SitemapUrl{
      url: "/profiles/#{profile.slug}",
      lastmod: profile.updated_at
    }
  end)
end

defp sitemap_posts do
  from(p in Post,
    where: p.private == false and is_nil(p.deleted_at)
  )
  |> Repo.stream()
  |> Stream.map(fn post ->
    %SitemapUrl{
      url: "/posts/#{post.slug}",
      lastmod: post.updated_at
    }
  end)
end
```

### Differences

- We replaced `Repo.all/1` with (surprisingly) `Repo.stream/1` . It’ll still allow us to work with all the records from the query, but with one difference - it returns a Stream, instead of an enumerable list.
- We had to wrap the whole part where we work with the Stream inside a **database transaction**. It’s a required step, as we have to be sure that the **data doesn’t change during the lifespan of the Stream** (you have to remember, that only a chunk of the entities from the query is inside our app’s memory at once).
- In order to work with the Stream, we can’t use the typical `Enum` methods - instead we use the `Stream` module, but it’s not a big deal - it has all the methods you would need, like `map`, `filter`, etc. Also take a look at how we’ve composed two streams - instead of the `++` operator, the [Stream.concat/2](https://hexdocs.pm/elixir/1.12/Module.html#concat/2) function had to be used.

## Read more

- [https://elixir-lang.org/getting-started/enumerables-and-streams.html#streams](https://elixir-lang.org/getting-started/enumerables-and-streams.html#streams)
- [https://hexdocs.pm/ecto/Ecto.Repo.html#c:stream/2](https://hexdocs.pm/ecto/Ecto.Repo.html#c:stream/2)
- [https://hexdocs.pm/elixir/1.12/Stream.html](https://hexdocs.pm/elixir/1.12/Stream.html)

Special thanks to [Kacper Latuszewski](https://github.com/latachz) ;)

Working with large sets of data can be slow, hard and annoying. Fortunately, Elixir and Ecto provide Streams - a simple, performant and elegant solution for all your data transformation problems.

TIL: Ecto’s Repo.stream/1

zap.svg

### So today I'm going to share with you a nice code snippet that we use for getting the dimensions of a React element.

What's so nice about it? It's a drop-in-and-forget solution, performant, not-so-large, doesn't need any external libraries, aaand.... **is Server Side Rendering compatible**, so you can use it safely with Next.js.

```ts
import { useCallback, useLayoutEffect, useState } from "react";

export function useElementSize() {
  const [size, setSize] = useState<[number, number]>([0, 0]);
  const [elementRef, setElementRef] = useState<HTMLElement | null>(null);

  const ref = useCallback((element: HTMLElement | null) => {
    setElementRef(element)
  }, []);

  useLayoutEffect(() => {
    const el = elementRef;

    const resizeObserver = new ResizeObserver((entries) => {
      const entry = entries[0]
      if (entry) {
        setSize([entry.contentRect.width, entry.contentRect.height]);
      }
    });
    if (el) resizeObserver.observe(el);

    return () => {
      if (el) resizeObserver.unobserve(el);
    };
  }, [elementRef]);

  return { size, ref };
}
```

#### So let's walk through what is actually happening there.

1. First interesting part begins with handling the ref. The pattern you would mostly often go with is just passing the ref as an argument to the hook... but it's not the case there, we want to separate the developer from having to initalize the `ref`, so we keep the reference to the element inside state (in order to trigger the layout effect and reinitialize the ResizeObserver if the element changed), and define our custom ref-function (take a look at that `useCallback` :)).
2. Then the `useLayoutEffect`. First of all, we use it because we want to do all the measurements just after all the DOM mutations finish, which makes up for a better feel of "snappiness". Then we initialize a quite simple [ResizeObserver](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver) which, suprise, observes the element resizing, and updates our measurements when needed.

You can modify this hook as you want to your needs - maybe you want to perform some other calculations than just the element size?

Also, take into consideration that you might want to use a polyfill for ResizeObserver, as it's not supported in all the browsers :)

Aaaand that's it, hope you learned something, I'll also leave some useful links below:

- Working example: https://codesandbox.io/s/awesome-gould-49hw4s
- useEffect vs. useLayoutEffect: https://kentcdodds.com/blog/useeffect-vs-uselayouteffect
- ResizeObserver API: https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver
- ResizeObserver Polyfill: https://www.npmjs.com/package/resize-observer-polyfill
- https://caniuse.com/resizeobserver

large_measuring.jpg

medium_measuring.jpg

small_measuring.jpg

thumbnail_measuring.jpg

measuring.jpg

A hook example for measuring React components, taking advantage of ResizeObserver and some not-so-popular React featues.

Measuring React Elements

large_branches.jpg

medium_branches.jpg

small_branches.jpg

thumbnail_branches.jpg

branches.jpg

large_stream.jpg

medium_stream.jpg

small_stream.jpg

thumbnail_stream.jpg

stream.jpg

**For over a year, we've been working on the new [AppUnite's website](https://appunite.com/). For the main (and only) backend, we've chosen Strapi. How did it work with our frontend application? What were the advantages and what were the drawbacks of using Strapi? We’ve described it all in this article.**

## The requirements

In the previous version of the website, a bit problematic thing was how the data was provided... in fact, all the content's been kept in `.json` files. So we needed a better solution - any change in the website's copy required a developer to *put it into the JSON file, commit it to the repo, make a PR, deploy...*

Another requirement was our "landings" system, which allowed us to create simple landing pages by composing ready components and providing some content. This meant that the new solution **should be extensible** enough to support some kind of **"dynamic" data structures**.

And last but not least: our blog. At the time, the posts were just markdown files, prepared, and served with a Phoenix application, which also provided a filtering system and a simple author panel for editing the articles. That meant, our solution of choice should have given us **some space to implement the filtering**, had a markdown editor, and should have given us the ability to create new user (author) accounts with specific permissions (so that an author could only edit the posts).

## The solution

It was clear that we needed a **headless CMS** (a CMS providing only the data layer and a panel for managing that data). Most of the solutions, though, didn't meet our requirements. For example, [Contentful](https://contentful.com/) doesn't provide an opportunity to create those "dynamic" data structures (the only option would be a JSON field and putting the content in JSON format...).

The solution that caught our eye was **Strapi** a self-hosted and very extensible CMS.

## What is Strapi?

According to the Strapi docs...

<Blockquote author={<a href="https://strapi.io/documentation/developer-docs/latest/getting-started/introduction.html">strapi.io</a>}>

The original purpose of Strapi was to help Boot**strap** your **API**. Now, Strapi is an open-source headless CMS that gives developers the freedom to choose their favourite tools and frameworks and allows editors to manage and distribute their content using their application's admin panel. Based on a plugin system, Strapi is a flexible CMS whose admin panel and API are extensible - and which every part is customisable to match any use case. Strapi also has a built-in user system to manage in detail what the administrators and end-users have access to.

</Blockquote>

So what does working with Strapi look like? Where does it shine, and where's the space for improvement?

## Strapi's pros

### 1. Extensibility

If we had to select one-word defining Strapi - that would be Extensibility. Strapi is just made to be built on. The whole data model is represented using code and is completely detached from the database - all that denotes that your application will be stored in a repo. In contrast, the database keeps the content, users, etc.

**The basic concept in Strapi is API**. Every app will consist of many APIs, each containing logic for its routes and optional things like data models (a representation of data in the database). For example, there can be an API for blog posts, another for post authors, an API for the content of a specific page on the website, etc.

<img alt="Strapi has a repeatable file structure for every of the APIs" src="https://strapi-appunite.s3.eu-central-1.amazonaws.com/Untitled_bbef3ad581.png" style={{ width: "200px" }} />

You can create the APIs manually, via CLI, or using the Strapi Content-Types Builder.

The `routes.json` file is essential and defines the connections between the route names (for example `/api/posts/[id]`) and the controller functions. We can define as many routes as we want and then implement them using the controllers for each content type.

Another thing we get is the controller. A controller is a set of functions, whose role should be handling the requests (for example, getting some data from DB and sending them back to the client). When we generate the API, Strapi automatically gives us the default controller, which handles the CRUD operations (but of course, we can always modify it and modify the default route handlers or add new ones).

Then, an API can have its data model - a representation of its data in the DB. For example, the `posts.settings.json` file contains the `Post` model with all its fields, relations, etc. Using the Content-Types Builder lets us select the content type's fields and then generate the whole API for our new content type (that is, the model, controller, etc.).

And then there are the API's services. They're meant to contain functions implementing business logic for each API (to separate the code from controllers, ideally only handling request-specific things).

For each of the API's files, Strapi provides a `strapi` object containing all the Strapi's APIs (like database's ORM and query engine, built-in utility functions, the services we've created, etc.).

All of this makes up for an excellent batteries-included backend framework for creating content-driven apps with a simple administration panel.

**Strapi has all the CMS functionalities and provides an opportunity to extend it on AppUnite’s website in a way we want.**

### 2. Plugins ecosystem

With that strong core, the Strapi team has created and maintained some official plugins and has made space for the open-source community to create even more 3rd-party plugins.

The essential one is the authentication ("Users & Permissions") plugin. It **manages the user accounts**, provides an API with the full authentication flow using multiple strategies and allows to create **various roles with different permissions** (you can set the permissions for each API route, each data-type operation and for the admin panel, which makes Strapi capable of being a regular backend for an app with user authentication).

![Strapi has a RBAC system, allowing to select specific permissions for each role](https://strapi-appunite.s3.eu-central-1.amazonaws.com/permissions_aa13247461.png)

Other plugins include managing a media library (while keeping the data on a separate server like AWS S3) with automatic image resizing, a plugin for mailing, an internationalization plugin, GraphQL plugin, etc.

Furthermore, you can even write plugins specific to your project and place them locally in the repo.

**Plugins can plug into literally every aspect of Strapi** - from adding new endpoints and data models to modifying or replacing the admin panel's components. For example, we've used this functionality to add a special button for previewing the posts on our blog without publishing them.

### 3. Powerful data types

Strapi also outstands simply as a CMS. Remember what I have mentioned about the landings system and the "dynamic" data models? **Strapi perfectly supports that!**

The first great thing about Strapi's data models are "components". For example, let's say we have a CTA banner across multiple pages on our website, but the banner's title is a bit different on each of them. So we can create a `banner` component in Strapi, define its data structure (let's say, a `title`, `description`, `button_name`, and `button_href`), and then reuse the structure between multiple Data-Types. It's important to know that components themselves aren't an entity - it's just a reusable data structure inside a data type.

Another excellent use case for components is just segregating the fields inside a Data-Type. For example, we have our company's About Us page, which consists of 4 sections. The first one is Hero, which's a component existent on basically all the pages. Then we have three different areas with content - all of them are separate components - and thanks to this, our data structure looks like this:

```tsx
interface AboutUsType {
  meta: Meta;
  hero: HeroType;
  about_us_section: {
    title: string;
    description: string;
    image: Media;
  };
  our_team_section: {
    title: string;
    description: string;
    video_youtube_id: string;
  };
  our_values_section: {
    title: string;
    description: string;
    values: {
      name: string;
      icon: Media;
    }[];
    read_more_button?: string;
    read_more_button_link?: string;
    image: Media;
  };
  case_study_banner: {
    background: Media;
    image: Media;
    category: string;
    title: string;
    button_link: string;
    button_label: string;
  };
  awards_section: {
    title: string;
    awards: { image: Media }[];
  };
  featured_content_section: FeaturedContentSection;
}
```

<details>
<summary>Not like this...</summary>

 ```tsx
interface AboutUsType {
  meta: Meta;
  hero: HeroType;
  about_us_section_title: string;
  about_us_section_description: string;
  about_us_section_image: Media;
  our_team_section_title: string;
  our_team_section_description: string;
  our_team_section_video_youtube_id: string;
  our_values_section_title: string;
  our_values_section_description: string;
  our_values_section_values: {
    name: string;
    icon: Media;
  }[];
  our_values_section_read_more_button?: string;
  our_values_section_read_more_button_link?: string;
  our_values_section_image: Media;
  case_study_banner_background: Media;
  case_study_banner_image: Media;
  case_study_banner_category: string;
  case_study_banner_title: string;
  case_study_banner_button_link: string;
  case_study_banner_button_label: string;
  awards_section_title: string;
  awards_section_awards: { image: Media }[];
  featured_content_section: FeaturedContentSection;
}
```

</details>

which just gives more readability in both the codebase and the Admin Panel.

Components can also be repeatable - we can use them for the repeating data structures on the page - take a look at `our_values_section.values` from the previous example!

![A list of components in the Strapi UI](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Untitled_1_41ff006dd2.png)

And the final use case for components, the one that really caught our attention because of the landings system - the Dynamic Zones. Strapi allows us to define a particular zone in the Content-Type, in which we can later pick any component from a pre-defined set. Then, on the frontend side, we just create a mapping between the Strapi components in the Dynamic Zone and the frontend app components, and *voilà*!

![Dynamic component picker in the Strapi UI](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Untitled_2_80398b51d0.png)

![A list of dynamic components in the Strapi UI](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Untitled_3_0f330f519c.png)

A thing worth noting is that Strapi's Content-Types also have a feature called relations. And relations are what you'd expect them to be - they create connections between multiple Content-Types - for example, a connection between an Author and their Posts, a relationship between a Post and Category, etc. Relations can also have different types, for instance, One-to-One, One-to-Many, etc.

The difference between relations and components is that relations allow you to set a connection between multiple entities, while components just let you reuse and segment the common data structures.

## Strapi's cons

### 1. Lack of support for database migrations

It's common to have multiple environments you run your apps within - apart from production, you may also want to have a staging and development environment, but Strapi doesn't make it easier. It's been, by far, **the most annoying problem we've encountered while using Strapi so far**.

A mechanism for database migrations should handle modifications (like renames) in the Content-Types. A nice-to-have would also be an option to copy one Content-Types data between environments which currently is practically impossible, and you either have to fill in the data by hand or just dump and restore the whole database.

### 2. No "default" deployment option

On the one hand - if you're taking a self-hosted solution, you'll have to *host* it your*self*. On the other hand - a **well-supported, preferred deployment option would be an excellent addition**. Just like Next.js has its Vercel, Gatsby has Gatsby Cloud, and so on.

The deployment of an app like Strapi requires you to set up a database, backup mechanism, etc.

Strapi currently works on preparing an opinionated cloud platform optimized for painless deployment of Strapi apps, but they still have a long way to go.

![There is some info about the planned Strapi Cloud, but it's not available yet](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Untitled_4_005898f244.png)

As for now, the easiest solution is using the default Docker image, and deploying it to a PaaS like [DigitalOcean](https://www.digitalocean.com/), [platform.sh](http://platform.sh) or [Render](https://render.com/)

### 3. While being extensible, also being opinionated

Although we didn't encounter any problems with the app architecture provided by Strapi, we see that as a kind of limitation - **Strapi forces a specific file structure in the project** and adding new features to your app works by creating a particular file that exports an object of a specific structure.

In our opinion, a better option would be to have an imperative API, in which adding new features (e.g., endpoints) would work by calling something from your code (look at, for example, [Keystone.js](https://keystonejs.com/)).

Also, Strapi won't allow you to fully control its configuration - basic changes to things like admin panel's Webpack config are possible, but you don't have a full control over the build and development pipeline. Currently, Strapi can't be as flexible as an app built using backend frameworks like Express.js or Nest.js.

Both of these limitations make **adding TypeScript to your Strapi app nearly impossible** - and if you managed to create a build pipeline - there aren't any typings available for the built-in Strapi's utilities.

If Strapi wanted to be more of a backend framework - they would have to rethink the architecture to make it more flexible to fit more apps - for example, those already built with other frameworks like Express.js.

### 4. Bugs

At the beginning of our journey with the new AppUnite website, Strapi wasn't the best documented and supported CMS. What's more, we can even say that the first setup annoyed us because of many difficulties. Why? Let's think about the situation when you only need a few commands to set up some tools. Cakewalk, right? But not this time. Following the documentation, we set it up and, at first sight, didn't encounter any issues. Unfortunately, the first attempt to change the Roles & Permissions brought an interesting error which turned out to be a [stable version issue](https://github.com/strapi/strapi/issues/6733). Possible solutions? Inject hotfix or downgrade version. Sounds engaging?

Another bug we encountered later was broken table names of the repeatable components. Spontaneously, we were not able to add any data in one of the Content-Types. What's more, the errors thrown by Strapi didn't tell us anything, which made the problem hard to debug. We finally found out that Strapi had first created a table for this repeatable component and then tried to access it, but with a different name (it was wrongly creating the plural form of the component's name). We resolved this issue by deleting the table Strapi had first created, but it **took some time and searching through Strapi's source code.**

To sum up - every solution isn't free of bugs, but in the case of Strapi - especially about a year ago - we felt like some of its parts weren't tested enough before publishing the stable version. In a matter of a **solution that's aimed up to enterprise apps - bugs like these shouldn't be acceptable**. What's good, at least, is the development team that reacts quickly and fixes the bugs in the nearest releases.

### 5. Community support

Many hours spent on Strapi Slack brought us to conclude that the **community didn't want to help**. The only answers were from the development team, and most of the articles had been prepared by them, so regular users (developers) weren't engaged in its development.

Recently, they have migrated from Slack to Discord. Maybe this step will make it more developer-friendly? We'll see.

### 6. Still, large parts of the documentation are poorly maintained

The main parts of Strapi's docs are OK, but the sections about backend customization, creating plugins and some of the guides seem outdated and do not cover all the features.

For example, when creating our plugin for the preview button of the blog posts, **we had to search through Strapi's source code** because the docs didn't cover the creation of the admin panel's frontend plugins.

## Summary

Having the experience gained over the last 1 year, would we select Strapi once again? **We think so!** Strapi, in fact, is one of its kind. There are lots of things that Strapi does *well*, and looking at the way Strapi is being developed - the drawbacks are being worked on and about to be improved! If you want to learn more about it - **we highly encourage you to take a look at Strapi's [website](https://strapi.io/) and [docs](https://strapi.io/resource-center).**

Meanwhile, thank you for reading, and see you in the next article! AUUUUUUU

Adam Siekierski

Hi there 👋

Hit me up 📞

Measuring React Elements

TIL: Cleaning your Git repository by removing the unused branches

TIL: Ecto’s Repo.stream/1

AppUnite & Strapi one-year relationship