
## Intro

Working on a project for years forces us to take a deep breath and rethink our architecture once in a while, doing that in smaller steps helps us adding more features to the project without putting the whole development on hold for weeks or even months.

## Problem
![Collapsing building](https://media.giphy.com/media/geDYq73orMiMLQ1bH5/giphy.gif)

I have been working at my curent job for 2,5 years now and I have seen the project since it's initial commits.
The decision has been made to make the stack rather exotic - Svelte as a renderer, Tailwind as a CSS abstraction and TypeScript to let us sleep better at night. Later we also decided on adding some Rust WASM logic in.

Just like most frontend projects we started tiny with a very well known folder structure to most frontend developers, splitting the source files into:
- components - the most common pattern you can spot throughout frontend projects, a singular directory where you'd put all your custom components
- constants - we do have hardcoded values in our code so you will want to place them somewhere to keep it clean
- icons - well these are SVGs that we have converted to .svelte files so we can change different properties on them, these could just be placed in the components directory if one prefers it that way
- services - the portal to another dimension, here lay all the API related queries and commands
- stores - at some point you will need a global state in your application and that's where we would put it, in React world you'd probably use something like Redux (is it still a thing?)
- styles - if you go on Twitter and read people fighting about wether using Tailwind is a good idea or not, you will see many people are against it because it makes the markup cluttered, well - we have noticed that it is true and sometimes it makes sense, but as you develop custom styles for your elements you can either encapsulate them in a custom component, create a separate style for them using the Tailwind config or just create a CSS class with @apply - we found the latter to be the easiest to maintain in the long run
- utils - the famous util folder, he lays pretty much EVERYTHING that doesn't fit anywhere else, let's face it - it is a pile of garbage
- views - often called pages, is a directory where only the page related components are placed, and in the beginning we would only put the components that could be called 'a page' in here
- types - a set of d.ts files that simply model our data

This structure worked fine as long as the app was poor in features, but now as the app has grown to be over 30 pages, each handling a different use case and context; the structure has started to evolve by itself.
Continuously working on the project we could notice where the some of the patterns started failing, applying changes as we go, we would find some way to allow the app to scale.

In the beginning the app would consist of a couple of tightly coupled features, but after a while the business needs increased and the app became a set of features which were either tightly coupled or not related to each other at all.

One of the biggest mind shifts was to allow ourselves to include other feature-related files in the pages folders, from now a page would simply mean a feature and most of it's logic and components would be stored there unless they can be reused.
This allowed us to get rid of clutter from components, utils and stores directories where we used to mix different features before.

Another crucial shift was to get used to inferred types instead of relying on type definitions we annotated ourselves. 
A tool that helped us a lot with that is `zod` - a TypeScript schema validator and parser. 
From now on we would be parsing our API responses to make sure they match the contract instead of assuming that the data we receive is structured correctly. 
This would also allow us to handle invalid API responses in the runtime and handle them as errors.

## Moving forward

I have spent last week on reading about different architecture approaches - Layered, Hexagonal, Onion etc.
Most of these architectures have a lot in common, but they are usually well described in context of building a backend and some parts simply can't be transcribed to frontend directly.

No matter which architecture mentioned above you pick, you will find they usually focus on having a Domain layer as a base, this layer usually consists of entity definitions and code that describes the business rules using the same language as the domain experts in your business would use.
Sometimes this layer is wrapped in some kind of repository pattern or splits the domain into model and services.

Next, usually you will either have one or more layers related to Application services or use cases, that are simply pieces of logic that we need to apply on top of the domain layer to be able to structure your procedures. 

Other layers will usually be some kind of ports and adapters that form a Infrastructure layer that can be split up into Gateways, Controllers and Presenters that are supposed to serve the UI, Devices, DB and generally the outside world.

## Frontend duties

What tasks do we perform on the frontend?
Well, obviously frontend and backend do completely different jobs, and even if in theory the backend should take care of most domain related logic it sometimes can't.

Most frontend applications would do just fine as an interface to the backend - we create a form, maybe validate it and then send it to the backend to do the rest for us.

The truth is that it's almost never as simple as that, because if it was we would not need all these JavaScript frameworks that we rely on nowadays.
Our goal is to serve the end user and provide them with a stable, snappy user experience - and there is nothing as annoying as a poor frontend that crashes without a reason. Say what you want, but if the API takes 2 seconds to respond or it throws a 500 in my face I will be fine. However if my frontend crashes and I lose all my unsaved data because somewhere in the code there was an unhandled null and I can't do my job because of that? Oh boy that grinds my gears.

Looking at the folder structure I added above, a basic frontend app would take care of multiple state values for improving the user experience - is the page loading, are we seeing an error, light mode, dark mode, keyboard navigations, modals, dropdown, tooltips, preferences, quick access menus. Additionally an app is usually a stitch of commonly used components like dropdowns and modals, as well as feature and page specific components like fligh seat selection component. 

If an application consists of many features it should be split up using these, if it doesn't then maybe it shouldn't.

We also have some form of connection to the outer world - REST API, WebSockets and also storage like cookies and localStorage.
And in case we need to program some business related logic we should be speaking the domain language.



// draft
// design oriented on features and domain needs
// dep incjection for maintainability
// ....


On a quest to build a perfect frontend architecture


## Intro

This project was an assignment for Noroff's Semester project. Being given a task of creating a small e-commerce website I wanted to raise the bar, I felt like a small e-commerce website was something I could easily create without using any libraries or frameworks. I have been reading about Vue lately and wanted to learn it, this project was perfect fit for it to be my first ever Vue project - it was complicated enough to make good use of all the tools the Vue ecosystem is built on.
![man jumping out of a car and chasing it](https://media.giphy.com/media/XKSa6XxpmHh1NEBvvl/giphy.gif)
I decided to go for Vue 3 (which is still in beta now), Vue Router, Vuex and Tailwind on the front-end. We were told to use Strapi as the backend, which I find a great tool for this task.

The source code for the project can be found [here.](https://github.com/bartektelec/shuuz-client)

You can view the live result [here.](https://bartektelec.github.io/shuuz-client/) Please keep in mind the server needs about 30 sec to start when you visit the website.

## UI Design

I started out with drawing wireframes of different pages in figma, the website was going to be a shoe e-commerce site, so websites like zalando.no, nike.com etc were a huge inspiration for the way I structured my pages.
I ended up drawing wireframes for the homepage, product/category page, product detail page, checkout page and the admin dashboard both on desktop and mobile.
![Figma wireframes](/assets/shuuz-wireframe.png)

After I have decided of what main, secondary and accent colors, as well as fonts I am willing on using for the project I started drawing simple components like cards in figma. It took me approx. 1 week to be finished with the whole design. Sticking to my predefined colors and fonts, as well as spacings made it easier to design, but also more appealing to the user.
![Full website design](/assets/shuuz-design.png)

## Coding

I found Vue to be very easy to start with, I believe anyone jumping straight out of HTML + Vanilla JS into the Vue train will enjoy their first ride.
Creating components in Vue is straight forward, these are included in their separate files, spread in to 3 sections that are template, script and style. This is just as easy as writing plain HTML and JS, or maybe easier? Why?
Vue does many things for you, and for most of this stuff it uses its own directives that look like custom HTML attributes.
`v-if, v-else, v-on:click, v-bind, v-model` are just examples of the Vue directives, and these are so easy to learn that there is no explanation needed.

Vue has it's own way of handling state, lifecycle methods and functions, which prevents the user from making a mistake and declaring a event callback function inside of a component on each re-render like many newcomers do when using React.

![Boom so easy](https://media.giphy.com/media/3o7btNa0RUYa5E7iiQ/giphy-downsized.gif)

Building components with Vue has been very easy and enjoyable from day one.

## Managing state and logic

The fun thing when using Vue compared to React is that Vue is a fully functional framework, not just a view library.
Vue has its own router and store module, which are just great and as easy to learn as Vue itself.

Vuex follows the same data-layer architecture as Redux - called "Flux". It is based on a store - being a wrapper around all the global states, mutations - which are exacly what they're; synchronous functions that mutate the state, actions - which perform asynchronous tasks, and getters - which are just a gorgous way of exposing our state in different ways.
Vuex was easy to understand, and easy to use, mostly because it is accessible from every Vue component in the app. It doesn't need to be imported or initiated in any way, it can be referred to from `this.$store` which is just great.
The only difference is when we want to use Vue 3 Composition API, which is the new API for managing the script part of the component. It is similar to React hooks and functional components in some way, and makes writing the logic inside of components much clearer.

![No groaning in my store animation](https://media.giphy.com/media/l2Je6Ae3mKzobqwbS/giphy-downsized.gif)

I used Vuex to store all the global state in the app, like user's JWT token, products in basket, favourites list and all the available products.
Using actions and mutations helped me a lot when doing features like storing current states in the localStorage.

## Boo-hoo TypeScript

I've been a huge fan of TypeScript recently, it made me code faster and more secure for the past few months, that's why I wanted to try out Vue 3 with TypeScript. Based on how great TypeScript works with React my expectations were really high, and Vue let me down in some way. Vue doesn't handle TypeScript as well as React does, it let me code a loosely typed code that I am no longer a fan of. For some reason it acted like it didn't really care. However I can't be too mad about that, they announced Vue 3 will support much more TypeScript but I used a beta build of Vue 3 so all I can do is wait and hope they will improve it later.
![Boo-hoo animation](https://media.giphy.com/media/WDelIGXnGdGdq/giphy-downsized.gif)

## Conclusion

The final product ended to be a simple e-commerce website, with admin dashboard for adding, editing products, and customizing the hero banner. There is still some room for improvement and I have already added a feature where you can zoom in the product picture when pointing your cursor on the image itself. I enjoyed working with Vue, even though I know there are multiple things I could've done better, it was really fun - and easy! Vue is a great tool that I am most likely going to use more in the future, because of it being so easy-going and all the modules being so well-fitted in the framework.


Shuuz - e-commerce site in Vue


## Intro

After going through two Udemy courses on React back in February (2020) I found myself very confused after "learning" so much stuff in a short period of time. I decided to start my own project from scratch.

The source code for the project can be found [here.](https://github.com/bartektelec/react-netflix-clone)

You can view the live result [here.](https://bartektelec.github.io/react-netflix-clone/)

## Video courses are overrated

![Animation of child falling when skiing fast](https://media.giphy.com/media/74u3n5M7SJx7O/giphy-downsized.gif)
I wrapped the word "learning" in quotes for a reason - now, after some time has passed I no longer believe in online courses (like the ones found on Udemy) to be a way of "learning", at least not for myself. I've done multiple courses on the platform before and it always ends up with me just watching the videos and not being able to use the _knowledge_ later. This **passive** way of learning is not right when learning something technical, that's why from now on I decided on learning stuff on my own, by actually doing a project from start to finish, and reading the docs when I am stuck. I find this way of learning to be much more effective, because in the end it's our practical abilities that matter.

## Confusion

The thing is, working with library such as React differs a lot from the workflow we're used to when working with plain HTML and JavaScript.
From now on the whole workflow was based on reactive properties (states), props, life-cycle methods and context.
![animation of confused man](https://media.giphy.com/media/toB3AnUDkqE3GENKx0/giphy-downsized.gif)
It was just a lot to process, and like always I barely could code a simple To-Do app after going through those courses.

## Project

I've spent approx. 1 month on building the project, first commit being 10th of March. Obviously if I've started today I would've probably finished it in a week, but like I said I wasn't really sure what I was doing back then.

I chose to use most of the tooling I've "learned" from the video courses, besides Redux.

Storybook was used as a UI testing library, as well as a documentation software for all the components that were styled for the project. Storybook is a tool where we can add our components, set the states these are available in and view how they look.

I used styled-components, as a CSS-in-JS styling library, which I still find great, the main thing I like about styled components is being able to pass props to the CSS values, as well as it being completely scoped from all of the other components. Styling with styled-components is actually extending a plain HTML element using `const StyledWrapper = styled.div` syntax, and adding all the styles as a template literal. It accepts SCSS, as well as media queries, and generates a JSX element with new unique classname.

## Blockers

I remember when I found out I was passing my props multiple levels down the React component tree and I knew I had to use some kind of global state. The problem was I had no idea how Redux or Context works. It obviously took some time to figure it out but I managed to solve it with the gorgeous `useContext` hook.
Yes, I used hooks for my project, even though most of the stuff I've learned from the video courses was Class-component based, there was just a short mention about hooks. I always like to learn from challenging myself, and that's also how I learned to use hooks, which I now find a much cleaner way of managing state in components.
![animation of man finding out where smell comes from](https://media.giphy.com/media/yoJC2ybBpQifyekSyI/giphy.gif)

## Improvements

I later improved some of the code, mostly using optimization techniques I've learned since.
When I coded the app in the first place I had no idea about the good and bad practices in React. I guess it's both a blessing and a curse that React gives us so much freedom to do stuff the way we want.
Wrapping my asynchronous API calls in a useEffect hook prevents the app from sending a request everytime the component rerenders.

![animation of man fixing his shoe with a tape](https://media.giphy.com/media/26ufiCwqYx1HetWfu/giphy.gif)

Wrapping my event handlers in a useCallback should increase the app's performance.
I was planning on using PropTypes library for static typing of component props, but since then I've learned to use TypeScript so I might as well rewrite the whole app in TypeScript instead.
I can tell the file structure in the project is difficult to understand, I don't know what I was thinking back then.
I still see some room for improvement, and I might rewrite the whole app in the future.

## Conclusion

It's been over 9 months since I started this project, a lot has changed and I've learned a lot since, however there is still plenty I don't know. React may seem easy to start with, however there is much more to learn than just passing props and changing state. Even though I feel very comfortable using React nowadays I still cannot say I know everything.


Lameflix - my first React project


## Intro

Builder is a creational pattern, that helps us avoid creating complex class constructors, using easy to read setter methods instead. It allows us to produce different types of objects using the same constructor code.

## Problem

![Confused builder](https://media.giphy.com/media/VIJxPwIvOsmL4XTikd/giphy-downsized.gif)

Complex class entities may get difficult to produce using only constructor arguments, providing more options for customization makes the constructor cluttered and difficult to read.

```ts
// Creating a red Enzo Ferrari with v12 6L engine, 2 doors, 1480kg weight and 651hp
const sportsCar = new Car("Ferrari", "Enzo", "red", "v12", 6000, 651, 2, 1480);
// or
const sportsCar = new Car({
  brand: "Ferrari",
  model: "Enzo",
  engine: { type: "v12", volume: 6000, hp: 651 },
  doors: 2,
  weight: 1480,
});
// results in error: color was not defined
```

## Solution

#### Fluent

![man rolling a long list](https://media.giphy.com/media/F0QWePzwQRewM/giphy.gif)

Using static class methods makes it easier to understand what we're building, by doing it step-by-step. It is like reading a blueprint.

```ts
// Using Fluent Builder pattern
// Great if the implementation will not be repeated many times
const sportsCar = new CarBuilder()
  .setBrand("Ferrari")
  .setModel("Enzo")
  .setColor("red")
  .setEngine({ type: "v12", volume: 6000, hp: 651 })
  .setDoors(2)
  .setWeight(1480)
  .getCar();
```

#### Concrete builders and directors

![Im doing my part animation](https://media.giphy.com/media/7T2R1eAIKnEJnAf5U8/giphy.gif)

Builder can be served as a complete blueprint aka. `Concrete Builder`, these classes are supposed to provide their own methods for creating parts of the instance and can be based on a Fluent Builder Pattern.

These `Concrete Builders` when passed to a `Director class` will be read and built in the same order every time no matter what blueprint we pass to the `Director`, however `Concrete Builder` methods will decide how the final instance will look like.

```ts
// Using Classic Builder pattern with Director
// Creating blueprints for our builds and passing it to the director
const carBuilder = new FerrariBuilder();
const carDirector = new Director(carBuilder);

carDirector.buildCabriolet();
carBuilder.getProduct(); // Returns a Ferrari object with no roof

carDirector.buildFullCar();
carBuilder.getProduct(); // Returns a Ferrari object with roof
```

## Code examples

### Fluent builder

```ts
class CarBuilder {
  private brand: string;
  private model: string;
  private engine: Engine;
  private color: Color;

  constructor() {
    this.element = new Car();
  }

  public setBrand(brand: string): Car {
    this.brand = brand;
    return this;
  }

  public setEngine(engine: Engine): Car {
    this.engine = engine;
    return this;
  }

  public setColor(color: Color): Car {
    this.color = color;
    return this;
  }

  public getProduct(): Car {
    return new Car(this);
  }
}
```

### Concrete builder + Director

#### Concrete builder

```ts
class FerrariBuilder implements Builder {
    private product: Car;

    constructor() {
        this.reset();
    }

    public reset():void {
        this.product = new Car();
    }

    public addDoors():void {
        this.product.setDoors(2);
    }

    public addChassis():void {
        this.product.setColor('red');
    }

    public addEngine():void {
        this.product.setEngine({
            type: 'v12',
            volume: 6000,,
            hp: 651
        })
    }

    public addRoof():void {
        this.product.setRoof(true)
    }

    public getProduct():Car {
        const result = this.product;
        this.reset();
        return result;
    }
}
```

#### Director class

```ts
class CarDirector {
  private builder: Builder;

  constructor(builder: Builder) {
    this.builder = builder;
  }

  public buildCabriolet(): Car {
    this.builder.addChassis();
    this.builder.addDoors();
    this.builder.addEngine();
  }

  public buildFullCar(): Car {
    this.builder.addChassis();
    this.builder.addDoors();
    this.builder.addEngine();
    this.builder.addRoof();
  }
}
```

## Relations with other patterns

To me this pattern reminds me of strategy, it is based on _blueprints_ just as strategy is based on, well _strategies_.
It provides us with an interface that uses similar methods but produces a different result based on what _blueprint_ is given.

### Sources

- https://refactoring.guru/design-patterns/builder


Hello there!
I’m Bart

About me

Hello, I'm Bartlomiej, a frontend developer based in Oslo, Norway.

Web development

UI Design

Other

My works

Shuuz

Bartek Telec

Foodie

Lameflix

FramX

Latest blog posts

On a quest to build a perfect frontend architecture

Shuuz - e-commerce site in Vue

Lameflix - my first React project

Get in touch