DEV Community: Team ORNIO

Create custom CRA (create-react-app) template with tailwindcss, twin.macro and goober

Redžep Murati — Wed, 14 Jul 2021 13:14:48 +0000

Have you ever felt the pain of starting a new React project?

Create the app via CRA, add your tools, add you common utilities, hooks, configs, structure, linters, etcetera etcetera.

It's frustrating having to start from ground zero each and every time. 😠

If only there was a better way?!

Being a developer I'm plagued with the same disease as everyone else. I hate repetitive tasks and if I can automate something, you can bet I will.

In this step by step guide we are going to explore how we can rewire React's CRA template to create a custom template bundled with our unique setups.

What is a CRA (create-react-app)?

Create React App is an official way to create single-page React applications.
Basically it is a zero-config toolchain that takes away all the hustle with hot reloading, live server and webpack configuration. It’s a one size fits all solution with only the bare minimum to get you up and running as fast as possible.

By default React team (shout out for an amazing work ❤️) has created two templates for us, a basic javascript template cra-template and a basic typescript template crate-template-typescript.

For the purpose of this guide I will be using a typescript template, but you can choose whatever suits you the most.

The only real difference between the two is typescript.

We will start by taking a look at CRA template provided by the React team.
It contains a template folder and two files template.json and package.json.

Template folder shares the same structure as a normal react app.
It has a public folder with a basic logo, manifest and robots files as well as an index.html file and a src folder where all your source code is.

As far as files go template.json is a file that represents how our package will look (actual package.json when app is created) it contains all our dependencies and scripts.

On the other hand, although a bit counter intuitive for beginners, the package.json file is just a representation of template information not app information. It contains template name, version and template files.

Now that we have covered the basics we can start building our own template.

We will start by creating our project via CRA by running the following command:

npx create-react-app --template typescript cra-template-tailwind-twin-goober

We are creating a clean CRA application so we can have a testing environment for our custom tooling instead of cloning one of the two templates locally and modifying it.

Keep in mind that the naming convention has to follow this standard: cra-template-[your_template_name] or in our case cra-template-tailwind-twin-goober.

This way CRA will know that it's an actual template instead of an app. That is a reason why typescript template is named cra-template-typescript.

Note that during installation cra-template prefix is comitted as seen with typescript template.

Let's start modifying 👷🏼

Navigate to package.json and add the following scripts under scripts section:

// package.json
...
   "cleanup-template": "rm -rf ./_template_",
   "generate-dirs": "mkdir _template_ && cd _template_ && mkdir template && cd template && mkdir src && mkdir public && cd .. && cd ..",
   "copy-resources": "cp -a ./src/. _template_/template/src &&  cp -a ./public/. _template_/template/public && cp template.json _template_/ && cp template-package.json _template_/package.json && cp .gitignore _template_/template/gitignore",
   "generate-template": "npm run cleanup-template && npm run generate-dirs && npm run copy-resources"
...

These scripts will help us generate our custom template on demand.

Now let's examine each script and what it does.

First on our list is cleanup-template script. This script's job is to clean up the template directory in our project. This one will be very useful for generating new templates over and over.
Next script is generate-dirs. This script is used to generate our folders, starting with template which is our template's route folder then template folder inside of it with source and public folders.
Next up is the copy-resources script. The job of this script is to copy all our files and move them to the template folder following CRA structure.
Last on our list is generate-template script, this one just combines previous scripts into one single execution.
This script will be used each time we want to publish/update our template on npm.

Beginner Tip: you run these scripts by typing the npm run command followed by script name. Ex. npm run generate-template

Keep in mind that these scripts are not final and we will be updating them as we progress further in this guide.

In order for the CRA template to work we will need to add two new files template.json and package.json. We will start by creating a template.json file in our root directory and copying the content of template.json of our CRA template of choice.

Next up we are going to create a package.json file in our root directory but since we already have one created by CRA we are going to name this one template-package.json.
Same as with template.json we are going to copy package.json found in CRA template.

We now effectively have the exact same copy of the CRA template as the one used to create our app initially.

Let's give it a go 😄

You can run locally your template with the following commands:

// generates template
npm run generate-template

// creates a new react app with your custom template
npx create-react-app --template=file:/path/to/your/dir/cra-template-tailwind-twin-goober/_template_

This is it guys now we have a starting point for our template. Now we can slowly add our tools and customize the template we have already created.

Adding ESLint, Prettier and Husky

We are going to start by installing ESLint globally with the following command:

npm i eslint -g

We can initialize eslint by running:

npx eslint --init

You will be prompted with some questions on how you plan to use ESLint.
As this is not really the subject of this guide I will just leave my answers down below.
Feel free to comment down below if you have any troubles with the setup.

How would you like to use ESLint?
A: To check syntax, find problems, and enforce code style
What type of modules does your project use?
A: JavaScript modules (import/export)
Which framework does your project use?
A: React
Does your project use TypeScript?
A: Yes
Where does your code run?
A: Browser
How would you like to define a style for your project?
A: Use a popular style guide
Which style guide do you want to follow?
A: Airbnb (matches closely my code style)
What format do you want your config file to be in?
A: JSON

That's it 😊 We have completed setting up our linter. All we need to do is include it now in our template resource script. If you navigate to your project root you can see an .eslintrc.json file. This file contains your linting rules.

We are going to add ESLint to our template by modifying our copy-resources script like this:

…
"copy-resources": "cp -a ./src/. _template_/template/src &&  cp -a ./public/. _template_/template/public && cp template.json _template_/ && cp template-package.json _template_/package.json && cp .gitignore _template_/template/gitignore && cp .eslintrc.json _template_/template/",
...

Since ESLint installed some dependencies in our project we also need to include them in our template.
We can modify our projects dependencies by modifying template.json file
Navigate to template.json and create a new field called devDependencies and copy the same named field in package.json.
Also since we are running our custom linter we can remove eslintConfig field from template.json.
After these changes your template.json should look like this:

Let's quickly add Prettier by running:

 npm install -D prettier

Once the installation is done navigate to the root directory and add .prettierrc.json file.

Prettier configuration is going to depend on your coding style, for the sake of simplicity i will share a link to mine.

We need to modify the copy-resources script as well as template.json and add the prettier with all its dependencies as a resource.

...
"copy-resources": "cp -a ./src/. _template_/template/src &&  cp -a ./public/. _template_/template/public && cp template.json _template_/ && cp template-package.json _template_/package.json && cp .gitignore _template_/template/gitignore && cp ./{.eslintrc.json,.prettierrc.json} _template_/template/ ",
...

Last on our list is husky. We will use husky together with the power of git hooks to automatically format and fix our files on every commit. Since we don't want all our files to be linted on every commit we will install a small package called lint-staged. Thanks to this package we can lint only staged files.

To install husky and lint-staged run the following command:

npm i -D husky lint-staged

After installation update template.json with your new dependencies.

...
"husky": {
      "hooks": {
        "pre-commit": "lint-staged"
      }
    },
"lint-staged": {
      "./src/**/*.{ts,js,jsx,tsx}": [
        "npm run lint --fix",
        "npm run format"
      ]
    },
...

As we can see from the code we added two new fields called husky and lint-staged.
These two fields in conjunction with one another will allow us to achieve our desired effect.

Cool 🎉 🎉. Now whenever we use this template our code style tooling will be ready to go out of the box.

Adding tailwindcss with twin.macro and goober

We are going to use tailwindcss due to the fact that it is a utility first css framework, fully configurable and customisable.
It plays really well with React’s philosophy on component composition hence the reason why it's my css framework of choice.
On the other hand twin.macro unlocks the full potential of tailwind css by allowing us to generate styled components from tailwind utilities. Since this is just a babel plugin it leaves no code behind.

Goober is a fairly new kid on the block. It is a css-in-js library that we will use to help twin.macro generate our styles. The reasoning behind goober is its size or lack thereof. Goober, unlike styled-components of emotion, is around 1kb. Yep you heard me right 🤯🤯.

We will start by installing tailwind like so:

npm install -D tailwindcss@npm:@tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9

In order to complete tailwindcss setup we will need a small yet powerful library called craco.
Craco will allow us to reconfigure CRA as needed. We will use it to run postcss with autoprefixer and tailwindcss.

Let's install craco:

npm i @craco/craco

Now let's navigate to template.json. We are going to modify a couple of things here.
First we will add craco as our dependency and then move under scripts section and add the following scripts:

...
 "start": "craco start",
 "build": "craco build",
 "test": "craco test",
 "eject": "react-scripts eject",
...

Note: You need to modify package.json as well with the same changes!

Besides that now we need to create a new file called craco.config.js and add the following code:

// craco.config.js
module.exports = {
  style: {
    postcss: {
      plugins: [
        require('tailwindcss'),
        require('autoprefixer'),
      ],
    },
  },
}

Next step is going to be initializing tailwind css. Run the following command in your terminal:

npx tailwindcss-cli@latest init

This command will create a basic tailwind.config.js file.

Now would be a good time to update our copy-resources script with tailwind and craco configs:

...
"copy-resources": "cp -a ./src/. _template_/template/src &&  cp -a ./public/. _template_/template/public && cp template.json _template_/ && cp template-package.json _template_/package.json && cp .gitignore _template_/template/gitignore && cp ./{.eslintrc.json,.prettierrc.json,craco.config.js,tailwind.config.js} _template_/template/ ",
...

Lets install twin.macro now by running the following command:

npm i twin.macro

In order for twin.macro to do its magic we need babel as well as babel macro plugin. We will install them by running the following command:

npm i -D babel-plugin-macros @babel/core @agney/babel-plugin-goober-css-prop babel-plugin-twin

Last but not least install goober by running:

npm i goober

Now would be a good moment to update our dependencies in template.json and add a new field called babelMacros like this:

...
 "babelMacros": {
      "twin": {
        "config": "tailwind.config.js",
        "preset": "goober"
      }
    }
...

To complete twin.macro setup we will create a .babelrc.json file with the following code:

// .babelrc.json
module.exports = {
  plugins: [
    '@agney/babel-plugin-goober-css-prop',
    'babel-plugin-macros',
    'babel-plugin-twin',
  ],
};

Don't forget to add this file to copy-resources script as such:

...
"copy-resources": "cp -a ./src/. _template_/template/src &&  cp -a ./public/. _template_/template/public && cp template.json _template_/ && cp template-package.json _template_/package.json && cp .gitignore _template_/template/gitignore && cp ./{.eslintrc.json,.prettierrc.json,craco.config.js,tailwind.config.js,babel.config.json} _template_/template/ ",",
...

Now navigate to src/index.ts file and add the following line to import tailwind css base.
While we are here we are going to set up goober as well.

import React from 'react';
import ReactDOM from 'react-dom';
import { setup } from 'goober';
import 'tailwindcss/dist/base.min.css';
import App from './App';

// setup goober
setup(React.createElement);

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

This is it guys. We have finished our template with custom boilerplate code.

Publishing template to npm

This is it people. We are in the endgame now (any MCU fans?).

As the final step let's deploy our template to npm.

Navigate to npm and create an account.(It's free)

After creating an account open up your terminal and run generate-template script.

Once the template is generated we can navigate to template folder in our terminal.

Type the following command to login to npm:

npm login

Once that is done now we can publish our package like so:

npm publish --access public

That’s it guys. Our custom template is ready to be installed.

If you have any questions feel free to comment down below and I will get back to you as soon as I can.

Happy hacking guys 😊

Links:
npm link of cra-template-tailwind-twin-goober
github repo

Simplify condition rendering in React.js

Redžep Murati — Thu, 08 Jul 2021 07:43:03 +0000

As a professional developer you are forced to stay up to date with the latest trends in technology. This year I've added Svelte to my bucket list as a new framework to learn.
While researching Svelte I was surprised by the way they handle condition rendering.
Take a look at this example found in their docs:

    {#if user.loggedIn}
      <button on:click={toggle}>
        Log out
      </button>
    {/if}

Everything is neatly wrapped with if clause and separated from normal flow.

After a quick prototyping I present to you the most powerful component I have ever written, an IF component.

   const IF = ({ condition, children }) => {
     if (!condition) return null;
     return <>{children}</>;
   };

By offloading condition into a separate component this will improve code cleanness and readability by quite a margin (for free).

Let’s imagine the Svelte example in our React app. It would go something like this:

…
return (
    <>
      {user.loggedIn && <button>Log out</button>}
    </>
  );
...

This is not an end of the world issue when you have just one condition but as our apps grow, so do the conditions.

Take a look at the same component now refactored to use IF:

…
return (
    <IF condition={user.loggedIn}>
      <button>Log out</button>
    </IF>
  );
...

Now it’s easier to track down conditions and debug faulty ones, plus the code looks way cleaner now that conditions are gone from JSX.

Hope you found this helpful ❤️

#SoMeIt

Trine Hoel — Wed, 30 Jun 2021 15:09:21 +0000

If I tell you that the proportion who use the internet has risen 85% from 1997 to 2020, it may not surprise you. The Internet and social media have become an addiction and a necessity for everyone, regardless of age. With so many people in the world using the internet, the topic of honesty is raised frequently.

As a committed marketer, I would not be so without telling my opinion about exactly my field - marketing. Marketing can be defined and understood as the activities one does to reach the audience, as well as increase the visibility of the company. The work involves recognizing the needs of the audience and giving them exactly what they need through our products and services.

Since reaching out to customers plays a huge role, the way you decide to approach them has also great importance therefore carrying your message with honesty and integrity plays a major role. The importance of this is great and it is therefore important to carry out their work in an honest way, by using social media for an honest purpose.

If the hashtag #SOMEIT does not make perfect sense, the point is to be what one pretends to be. SoMe is the abbreviation for social media and is the inspiration for #SOMEIT. If you post it on SoMe, so be (Me) it.

Tell the truth
As a company, you will always want to deliver fantastic results and mastery to gain more followers, but it is important for us in Ornio to distinguish between what is truth and what is a facade. It is a well-known fact that social media is adorned with facades and glossy images of everyday life, regardless of whether it is individuals or companies, success can come to anyone - regardless. Nevertheless, we want to market ourselves for the company we are. So when using social media, the goal is to market our business by sharing our journey and creating relationships in an honest way.

Success?
Is being an honest Business the recipe for success? Both yes and no. The benefits of using social media are many, including increasing visibility, gaining insight and increasing loyalty. By providing sincere information about the benefits we provide, as well as the values we stand for, we will have followers who share the same opinion that we share in our posts. It is these followers we create content for, and will share our journey with through various blog posts and SoMe posts. It is also worth mentioning that not all visibility is good visibility. Ornio wants to create interest and commitment for people who have the same interests and values as us, and it is this visibility our goal is.

Transparency
We want to post what is important to us and the values we stand for, and through this honesty we will get the supporters who motivate us to continue with the work we do. This openness also involves feedback from our supporters, and channels that are open to dialogue. We want to connect with our community and give them the feeling of sincerity. It is therefore important for us that our supporters know that there are people behind the posts, not just preconstructed data that only looks for the results.

In conclusion, I would like to take this opportunity to encourage all companies to use the hashtag #SOMEIT, to front honestly for companies on social media. For customers, this is exactly what can be most significant.

Sources:
(https://www.medienorge.uib.no/statistikk/medium/ikt/347)

Container/View Pattern in React inc.hooks

Redžep Murati — Wed, 23 Jun 2021 09:14:15 +0000

We at Ornio love clean, readable code. In order to achieve this we are in constant search for new techniques and methods to make our code as robust as possible.

Few years ago we switched from Ember to React. At first React seemed like strange unexplored territory where everything made sense and nothing did.
Questions started popping up. What's the best way to make a component ? When to make one ? How to keep them as reusable as possible ?

In search of answers I came across this article by Dan Abramov on Presentational and Container components. After reading it I instantly fell in love with the idea that it represented.

So what is the Container/View pattern?

Container/View pattern (also known as Presentational/Container, Thick/thin, Smart/Dumb) is a technique of splitting components into 'Containers' which are responsible for any stateful logic and data fetching and 'Views' which are responsible for data presentation.

If used right this pattern allows for immense scaling options in React applications. By keeping views clean of any logic we can reuse them as much as we want. But also now that all our logic is contained inside a container it allows us for faster and easier debugging.

Here is a simple example on how to implement this pattern.

Let's start by creating our view component. In our case it will be a simple user card showing a profile picture, name, location, gender and email of a user.

import style from "./Card.module.css";

const Card = ({ title, location, email, gender, image }) => (
  <section className={style.card}>
    <img
      className={style.cardImage}
      src={image}
      alt={title}
    />
    <div className={style.cardContent}>
      <h3 className={style.cardTitle}>{title}</h3>
      <span className={style.cardLocation}>{location}</span>
      <div className={style.cardContact}>
        <span className={style.cardMail}>{`email: ${email}`}</span>
        <span className={style.cardGender}>{`gender: ${gender}`}</span>
      </div>
    </div>
  </section>
);

export default Card;

Now let's add some style to make it pretty.

.card {
  display: flex;
  align-self: center;
  width: fit-content;
  background: #ffffff;
  box-shadow: 0px 2px 4px rgba(119, 140, 163, 0.06),
    0px 4px 6px rgba(119, 140, 163, 0.1);
  border-radius: 8px;
  padding: 24px;
  margin: 0 auto;
}

.cardImage {
  height: 80px;
  width: 80px;
  border-radius: 100px;
}

.cardContent {
  font-family: sans-serif;
  line-height: 0;
  margin-left: 20px;
}

.cardContact {
  display: flex;
  flex-direction: column;
}

.cardTitle {
  font-size: 20px;
  color: #112340;
  margin-bottom: 20px;
}

.cardLocation {
  font-size: 12px;
  color: #112340;
  margin-bottom: 22px;
  opacity: 0.85;
}

.cardMail,
.cardGender {
  font-size: 12px;
  color: #112340;
  margin-top: 15px;
  opacity: 0.65;
}

Voila. Our card is finished and ready to use.

Now here is where the magic happens. We are going to create a new component called CardContainer. Inside this component is where the logic happens. We are going to fetch a user from a random user api and display data to our card.

import { useState, useEffect } from "react";

import axios from "axios";

import Card from "@components/Card";

const CardContainer = () => {
  const [userData, setUserData] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const result = await axios("https://randomuser.me/api/");
      const user = result.data.results[0];
      setUserData({
        gender: user.gender,
        email: user.email,
        location: `${user.location.city}, ${user.location.country}`,
        title: `${user.name.title}. ${user.name.first} ${user.name.last}`,
        image: user.picture.thumbnail,
      });
    };

    fetchData();
  }, []);

  return (
    <Card
      title={userData?.title || "N/A"}
      location={userData?.location || "N/A"}
      email={userData?.email || "N/A"}
      gender={userData?.gender || "N/A"}
      image={userData?.image || ""}
    />
  );
};

export default CardContainer;

As you can see by isolating all the logic in the container our view component is clean and ready to be reused as many times as we wish.

Introduction of hooks in React

As we can see from Dan's blog with the introduction of hooks there is no need to package components like this. Since hooks allow us to isolate logic inside them and then just call them on demand, the need for a container is slowly fading away.

But as great as hooks are, they do not solve every problem, hence the reason why this approach is still widely used.

First let's move our container logic to a custom hook called useUserData.

import { useState, useEffect } from "react";

import axios from "axios";

export const useUserData = () => {
  const [userData, setUserData] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const result = await axios("https://randomuser.me/api/");
      const user = result.data.results[0];
      setUserData({
        gender: user.gender,
        email: user.email,
        location: `${user.location.city}, ${user.location.country}`,
        title: `${user.name.title}. ${user.name.first} ${user.name.last}`,
        image: user.picture.thumbnail,
      });
    };

    fetchData();
  }, []);

  return {
    gender: userData?.gender || "N/A",
    email: userData?.email || "N/A",
    location: userData?.location || "N/A",
    title: userData?.title || "N/A",
    image: userData?.image || "",
  };
};

Looks good right. Now our logic is inside a hook instead of a container.
But how do I mix them now ?
Well we can try making a wrapper.
Let's do that.

import { useUserData } from '@hooks/useUserData';

import Card from "@componets/Card";

const UserCardContainer = () => {
  const {
    title,
    location,
    email,
    gender,
    image,
  } = useUserData();

  return (
    <Card
      title={title}
      location={location}
      email={email}
      gender={gender}
      image={image}
    />
  );
};

export default UserCardContainer;

Now isn't this just another container? This creates a new arbitrary division where now ur logic is separated in 3 different files.
To me this was a really hacky way and it just wasn't as clean as i was hoping for.
I loved the idea of hooks and the idea of container/view pattern so I wasn't ready to give up yet.
To the internet!
After some digging online I have found a solution in the form of a library called react-hooks-compose.

What this library allows us to do is compose our views with our custom hooks removing the need for a container.

Let's compose our useUserData hook and Card component.

import composeHooks from "react-hooks-compose";
import { useUserData } from "@hooks/useUserData";
import Card from "@components/Card";
import CardContainer from "@containers/CardContainer"

// composing card with our hook
const ComposedCard = composeHooks({ useUserData })(Card);

const App = () => {
  return (
    <div className="app">
      <ComposedCard />
      <CardContainer />
    </div>
  );
};

export default App;

Success at last 🎉 🎉

Personally I think that container/view pattern in any shape or form is a great way to separate the concerns and keep your code as reusable as possible.
We at Ornio love this approach and will continue to use it as it helped us scale faster and it made building and testing components so much easier.

Hope you found this article helpful.

Links:
Dan's original post
react-hooks-compose
code

Ornio´s truths

Trine Hoel — Fri, 11 Jun 2021 13:09:51 +0000

When creating Ornio's values, the goal was to be able to utilize the values for own development and better collaboration. The values should function as a set of rules in the workplace, and if challenges arose, the values should put us back on track. For our partners and customers, the values should show what we stand for and how we want to deliver our best - and so it has worked. Whether it's potential customers or colleagues, we have four truths that we value highly. Within my own field, I want to shed light on our four truths and how we want to market ourselves in the future.

We innovate

The first truth is that our services and products should not be available everywhere. We want to constantly develop and improve, so that we are at the top of every wave. For marketing, this truth will stand for how we continuously want to find new ways to engage, communicate and be creative. We want to be regularly updated and create solutions for how we can reach the target group in the best possible way. Social media is constantly growing, and every day new trends are created. It is therefore very important to have an interest in the subject and the challenges the market offers.

We are committed

We are committed to delivering a unique product that we at Ornio are proud to present. This requires cooperation and loyalty, both internally and externally in the company. As an interdisciplinary team, it is therefore important to share knowledge to achieve results and utilize our burning interest in achieving the goals. Commitment involves, among other things, maintaining deadlines, fulfilling wishes and keeping agreements. We at Ornio use this truth to constantly remind ourselves that we are committed, for ourselves and others, to do our best.

We are credible

The third truth is that we should be trustworthy and sincere at all times. For social media, this is a central value, where we want to convey sincere information and commitment in what we post. Nothing should be done halfway or feel wrong. For us, it is important that our followers and customers feel safe and taken care of, in the information we provide. Within the team, it is this value that makes us good, in that honesty makes the products and service better. Because if one does not show honesty, we will not be challenged by each other to do a better job.

We're excellent

This is a truth we are proud of. We at Ornio are good at what we do because we are a team. By learning from each other, collaborating, sharing knowledge and praising each other, we will always grow for the better. Knowledge is challenged by constantly new courses, collaboration is improved with weekly team building and patience is challenged with an eternally long period of home office in the pandemic.

...

Finally, I would like to thank you for reading this blog post and encourage you to follow us further for more posts and updates. Feel free to send a message on social media if you have requests for content or blog posts, by using this Link.

Code review and clean coding principles at ORNIO

EgzonaVllasaliu — Wed, 12 May 2021 10:24:39 +0000

How to make a good review of the code? Where to start? What you should remember? Why is clean coding important?
I will show you my practices which will help not only with the product itself, but also make wonders for the development team.

Code review

Code review helps give a fresh set of eyes to identify bugs and simple coding errors before your product gets to the next step, making the process for getting the software to the customer more efficient. Simply reviewing someone's code and identifying errors is great.

Here at Ornio we use this guideline to do an organised code review.

Ask open-ended questions instead of making strong or opinionated statements. Offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. These reviews assume the reviewer might be missing something and ask for clarification instead of correction.
Once a reviewer completes their review, they can either mark it approved, block the review with change requests, or not set a specific status, leaving it in a “not yet approved” state.
Flexible on the practice: sometimes, certain comments are addressed by the author with a separate, follow-up code change. For changes that are more urgent than others, reviewers should try to make themselves available for quicker reviews.
Leave as many comments and questions as needed. If the revision does not address all of them, they will note those as well. When the conversation gets into a long back-and-forth, reviewers should try to switch to talking to the author in-person instead of burning more time using the code review tool.
Proactively reach out to the person making the change after they do a first pass on the code and have lots of comments and questions. This will save a lot of time, misunderstandings, and hard feelings this way. The fact that there are many comments on the code indicates that there is likely some misunderstanding on either side. These kinds of misunderstandings are easier identified and resolved by talking things through.
Make it clear when changes are unimportant nitpicks. They usually mark comments like these distinctively, adding the “nit:” prefix to them. Too many of these can become frustrating and take the attention away from the more important parts of the review, so reviewers aim to not go overboard with these.
Realize that too many nitpicks are a sign of lack of tooling or a lack of standards. Reviewers who come across these frequently will look at solving this problem outside the code review process. For example, many of the common nitpick comments can be solved via automated linting. Those that cannot, can usually be resolved by the team agreeing to certain standards and following them—perhaps even automating them, eventually.
Ensure that all engineers take part in the code review process—even those that might be working on solo projects.
Have hard rules around no code making it to production without a code review—just as business logic changes don’t make it to production without automated tests.
It is the author’s responsibility to submit PRs that are easy to review in order not to waste reviewers’ time and motivation:
- Scope and size. Changes should have a narrow, well-defined, self-contained scope that they cover exhaustively.
  - For example, a change may implement a new feature or fix a bug. Shorter changes are preferred over longer ones. If a PR makes substantive changes to more than ~5 files, or took longer than 1–2 days to write, or would take more than 20 minutes to review, consider splitting it into multiple self-contained PRs.
  - For example, a developer can submit one change that defines the API for a new feature in terms of interfaces and documentation, and a second change that adds implementations for those interfaces.
- Review fewer than 400 lines of code at a time.
- Do not review for more than 60 minutes at a time
- Only submit complete, self-reviewed (by diff), and self-tested PRs (Authors should annotate source code before the review). In order to save reviewers’ time, test the submitted changes (i.e., run the test suite) and make sure they pass all builds as well as all tests and code quality checks, both locally and on the CI servers, before assigning reviewers.
- It is customary for the committer to propose one or two reviewers who are familiar with the code base. Often, one of the reviewers is the project lead or a senior engineer.
- Project owners should consider subscribing to their projects in order to get notified of new PRs.
- As a reviewer, it is your responsibility to enforce coding standards and keep the quality bar up.
- Reviewing code is more of an art than a science. The only way to learn it, is to do it; an experienced reviewer should consider putting other less experienced reviewers on their changes and have them do a review first.

Maintainability

Read the tests. If there are no tests and there should be, ask the author to write some. Truly untestable features are rare, while untested implementations of features are unfortunately common. Check the tests themselves: are they covering interesting cases? Are they readable? Does the PR lower overall test coverage? Think of ways this code could break. Style standards for tests are often different from core code, but still important.
Does this code need integration tests? Sometimes, code can’t be adequately tested with unit tests alone, especially if the code interacts with outside systems or configuration.

Code Reviews for New Joiners

The codebase is new, the style of programming is different than before, and people review your code very differently. So should code reviews be gentler for new starters, to get them used to the new environment, or should they keep the bar just as high, as it is for everyone else?
- Use the same quality bar and approach for everyone, regardless of their job title, level or when they joined the company. Following the above, code reviews have a kind tone, request changes where needed, and will reach out to talk to reviewers when they have many comments.

Clean coding

Decide on the indentation and keep it that way, follow standard conventions.
- The code should be divided into logical units and it’s important to keep the style consistent throughout the whole document. In most of the programming languages, spaces and indentations do not affect the function. If you are using an IDE, it is recommended that you create a formatted config so everyone uses the same one.
- Make comments
  - Comments will help you and others understand why you did what you did.
    - Always try to explain yourself in code.
    - Don't be redundant.
    - Don't add obvious noise.
    - Don't use closing brace comments.
    - Don't comment out code. Remove it instead.
    - Use as explanation of intent.
    - Use as clarification of code.
    - Use as warning of consequences.
- Consistent name scheme
  - Be consistent. If you do something a certain way, do all similar things in the same way. Naming needs to stay consistent, otherwise, it will be very difficult to find things inside the document.
- Don’t repeat code
  - Repeating code will make your document very long and it will break the reading flow. If you have pieces of code that will be used more than once, it is preferable to make a separate file.
- Avoid writing long code lines
  - Writing long lines of code makes it very difficult to read, moving back and forth horizontally, losing any sense of what it’s actually written. Style and indentation will help with this.
- Break down a big task into smaller chunks
  - A whole new feature will never be just a few lines long. Even with comments, a 500-lines function will still be a pain to browse, understand and edit. Your best choice is to break down the big task into a smaller chunk of code.
- Organize your program into smaller files
  - Having a file with thousands of lines of code doesn’t help anyone, but broken down into shorter files organized based on function or feature will help you get right to the point when something needs fixing. Having the whole code organized in files and folders is very good for maintainability, especially if different teams and people are working on it.
    - Small.
    - Do one thing.
    - Use descriptive names.
    - Prefer fewer arguments.
    - Have no side effects.
    - Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.
- Keep it simple, write clever code that is also readable
  - Write clever code, but the main focus should be on readability and maintainability. If the code is kept short it is easier to go through, but if it’s too smart, it will take too much time to understand and edit it. You know that your code was too clever if you can’t read it after 3 months. So be clever but not too much!
- Code refactoring
  - Every developer knows this – you write some code because you want to finish the feature and in the end, it works. When you then look at it after some time you think – did I really write that? I could have shortened it so much! So you start rewriting that piece of code better, probably shorter, without changing any functionality. Ps. It is the developer’s responsibility to create tasks for refactoring the code.
- Delete unnecessary code
  - You wrote new code, great. Is the new code working? If yes, then just delete the old one! There is no point in keeping the old code, and comment it out. It will just look messy and unnecessarily long.
- Must avoid doing:
  - Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
  - Fragility. The software breaks in many places due to a single change.
  - Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
  - Needless Complexity.
  - Needless Repetition.
  - Opacity. The code is hard to understand.
  - Try to avoid temporary variables.
    - Using too many temporary variables can cause memory leaks, because of that try to use temporary variables only when:
      - statements are getting too long and too complex
    - Don’t use temporary variables when:
      - Return a value from a function:

Don’t do:

function name(){
  const message = "Hello";
  return message;
}

Do:

function name(){
  return "Hello";
}

IE adds double XMLNS on SVG markup when converting to string

Flamur Mavraj — Mon, 10 May 2021 02:29:47 +0000

We where tasked/needed to serialize SVG files on a project we are working on, and while the first implementation worked well on most (normal) browsers, it did not take too long time before we got some complains that our images where not being displayed properly.

After some debugging we found out that all these cases where related to users using IE. And after dusting of my Windows laptop and started testing we could reproduce the issue ❤️ (as developer I get a relief when I can reproduce an bug)

After a quick search on Google for IE svg adding double xmlns following two links helped understanding the issue and led to a fix:

First implementation (Does NOT work on IE)

We do use Figma to design and create our SVG's, when exporting, the SVG contains the xmlns-tag by default.

Here is an SVG example showing a red circle where the xmlns-tag is already set:

<svg height="100" width="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red" />
</svg>

The serialize function we used is straight forward using XMLSerializer:

export const svgSerialize = (el: SVGSVGElement) => new XMLSerializer().serializeToString(el);

This will result in following result:

<svg height="100" width="100" xmlns="http://www.w3.org/2000/svg"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red"/></svg>

And as said this worked perfectly on all other browsers expect Internet Explorer. Here is the result of same image on IE:

<svg xmlns="http://www.w3.org/2000/svg" height="100" width="100" xmlns="http://www.w3.org/2000/svg"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red"/></svg>

Yes you spotted right, yet another xmlns="http://www.w3.org/2000/svg"-tag has been added to the SVG :(

Browsers are strict on XML parsing and therefor the above image will not be displayed!

After some trial and errors here is how we fixed the issue.

The solution

First we removed xmlns tag from our SVG:

<svg height="100" width="100">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red" />
</svg>

And our new svgImageToString function looks like this:

export const svgImageToString = (el: SVGSVGElement) => {
    // Serialize the SVG object, this will add an xmlns on IE
    const serialized = new XMLSerializer().serializeToString(el);

    // We then do convert back the SVG serialized string to new SVG 
    const parser = new DOMParser();
    const newSvg = parser.parseFromString(serialized, "image/svg+xml");
    const newSvgEl = newSvg.firstChild as SVGSVGElement;

    // We check if the new SVG has xmlns if not we added to it
    if(!newSvgEl.hasAttribute('xmlns')){
        newSvgEl.setAttribute('xmlns', 'http://www.w3.org/2000/svg')
    }

    // We serialize the new element again and return the result
    return new XMLSerializer().serializeToString(newSvgEl)
}

You are probably thinking why converting the SVG serialized string back to SVG object using DOMParser, due to our complex SVG's we where not able to detect and remove the double xmlns-tag in another way (yes we tried with regex).

Hope this will help others that will face this issue 😊

Comment if you have other alternatives to the solution!

Cheers :)

A Woman’s Guide to Project Management

Aulore Hoxha — Fri, 07 May 2021 13:25:38 +0000

Every Industry has its unique characteristics. Information Technology it's no different. But it’s always about effective management of workload and change, of a systematic approach to all stages and controlling of different types of events in the course of the project life cycle.

If we want to answer a basic question first, what is project management? In simple terms, it is getting work done in time and budget. If we would like to dive into some depth we say Project Management is the process of creating methodologies, using tools, and following processes to plan and execute projects in a successful way. Where we use teams and resources to complete tasks within the deadline, cost, and scope of the project, while we pass five main project life cycle stages: initiation, planning, execution, monitoring, control, and closure.

In order to execute projects in a perfect manner we use different methodologies from Waterfall to Kanban to Scrum and many others, all with the same objective; taking an idea and bringing it to fruition.

Now, assuming we have mastered the technical skills of project management and implementation, is this all there is to know? And is this all we need to do?
Absolutely not! There are other key elements we need to have in mind if we really want our projects to succeed:

Creating proper communication channels
The ability to have the proper language on communicating important information to all relevant parties is crucial to project success. Remember that it's not always easy to get everyone on the same page.

Stimulating teams
Motivating people over the course of a long effort doesn't always come in handy. But it is important to motivate team members to do their best work even when deadlines get tight and projects get tricky

Adaptability
You need to know how to roll with the punches and make the necessary adjustments to move forward even in the face of unexpected issues.

Resourcefulness
You don’t always have every tool to succeed in our projects but that should not stop you. Instead of giving up when you come across an issue you are not prepared about, you need to become determined to find a solution even if it takes a little elbow grease to do so.

Teamwork
Project management is all about working together in a group. Being cooperative, collaborating, creating easy environments to work in, talk to, and being fair to everyone else is as much important as any other element.

If you have any questions or need help with Project Management ping me/us.
We do also provide PM as a Service for our customers, If you are interested to find more contact me/us or schedule a meeting for more information.
Link

Applications that Ornio uses the most

Diellëza Namani — Mon, 29 Mar 2021 14:10:02 +0000

Working from home has made us use even more tools that we would not necessarily have used if we would be working from the office. This process has made us become more aware of what is worth investing in and which ones can ease our work strategies and goals. These are the apps that we use and we figured you might find them handy:

Hubstaff

(Ranking: 4.5/5)

This application is the perfect one to monitor the work from home. It tracks the time and productivity by also being able to create reports and timesheets for more detailed information regarding what has been done.