Forem: Dinesh Balaji

React - Server Components - Introduction and Initial Thoughts

Dinesh Balaji — Sun, 27 Dec 2020 14:06:39 +0000

Just before Christmas, the React team gave an early Christmas present, Server Components a.k.a the zero bundle size components. Let's have a look at what they are, what they bring to the table and my thoughts.

Before we start, just want to let you know that the best resource for a deeper understanding would obviously be the RFC and the introduction video from the React team. I put this together for people who are light on time and to share my thoughts and understanding.

You can find the entire source for this post here. It's a fork of the actual demo repo from the React team. I just simplified the components for easier understanding. All kudos go to the React team.

With the introduction of the Server Components, the existing components have been renamed as Client components. In fact, we have three types now:

Server Components
Client Components
Shared Components

Server Components

Let's look at some of the important features of the Server components.

Zero Bundle Size

They are zero bundle size because they are rendered on the server and only the rendered content is sent to the client. This means they do not add to your client JS bundle size. Let's look at an example,

// BlogPost.server.js - A Server component.

import { renderMarkDown } from '...'; // Server only dependency.
import {getBlogPost} from './blog/blog-api';

export default function BlogPost({blog}) {
  const blog = getBlogPost(blog.id); // Get blog post from database directly.

  return (
    <>
      <h1>{blog.title}</h1>
      <p>{renderMarkdown(blog.markdown)}</p>
    </>
  );
}

Things to note here,

All server components are suffixed with server.{js,jsx,ts,tsx) (At least for now).
Since they are not sent to the client, we can have code that accesses server resources like database, internal API's etc.
Since all this happens in the server, the package you imported for rendering the markdown is not sent to the client, only the rendered content is sent. This is a significant reduction in the Client JS bundle size.

The component itself is straight forward, it fetches the data from the database and renders the content.

Render Format

If you have noticed, I have said that the content is rendered and not HTML. This is because Server components are not rendered to HTML but rather to an intermediate format.

If the above component was the only component in your app, this is what would be returned from the server.

J0: [
    ["$", "h1", null, {
        "children": "Blog 1"
    }],
    ["$", "p", null, {
        "children": "unt aut..."
    }]
]

As you can see, only the rendered markdown is sent to the client and not the library itself.

Now you might be wondering why not HTML and this format? (I don't know the format's name.. 🙃). Let's see why in the next section.

State and difference from SSR

Let's look at a primary difference between Server components and SSR. SSR generates the HTML on the server which is then sent to the client for rendering by the browser. This means the content itself is static and you cannot have interactive markup.

However, since Server components use this intermediate format instead of HTML it allows them to have Client components that have interactive behaviour. Make no mistake, Server components themselves, cannot have state or event handlers, in other words, they cannot make use of useState, useEffect etc. However, they can have Client Components which in turn can have state.

Let's add a like button to the BlogPost component that when clicked increments the number of likes for the blog post.

// BlogPost.server.js - A Server component.

import {getBlogPost} from './blog/blog-api';
import LikeButton from './LikeButton.client';

export default function BlogPost({blog}) {
  const blog = getBlogPost(blog.id);
  return (
    <>
      <h1>{blog.title}</h1>
      <p>{blog.markdown}</p>
      <LikeButton blog={blog} /> // A Client component.
    </>
  );
}

// LikeButton.client.js - A Client component.

import {likeBlogPost} from './blog/blog-api';
import React from 'react';

export default function LikeButton({blog}) {
  const [likesCount, setLikesCount] = React.useState(blog.likes);

  const handleClick = () => {
    setLikesCount(prev => prev + 1);
  };

  return <span onClick={handleClick}>Likes: {blog.likes}</span>;
}

The BlogPost Server component has a child component LikeButton, which is a Client component that handles user interaction. The LikeButton component is free to make use of useState as it is a Client component and it also updates the local state on click.

Thus a Server component cannot have state itself, but it can make use of a Client component to maintain state and handle user interactions.

Note that the LikeButton component is only updating the local like count and not the count in the server. The point of this example was to show that Client components can have state and user interaction.

State Tree

To understand this, let's expand our example to have a BlogPostList Server component that renders a list of blogs using our BlogPost Server component.

// BlogPost.server.js - A Server component.

import {getBlogPosts} from './blog/blog-api';
import BlogPost from './BlogPost.server';

export default function BlogPostsList() {
  const blogs = getBlogPosts();
  return (
    <>
      {blogs.map((blog) => (
        <BlogPost blog={blog} /> // Uses a server component.
      ))}
    </>
  );
}

Let's also update the LikeButton component to replace the state variable for likes with the likes from the props. Let's also add a callback function that hits the server to update the likes count of the particular blog post.

// LikeButton.client.js - A Client component.

import {likeBlogPost} from './blog/blog-api';

import React from 'react';
import {useLocation} from './LocationContext.client'; // Experimental API for POC.

export default function LikeButton({blog}) {
  const [, setLocation] = useLocation();
  const handleClick = async () => {
    await likeBlogPost(blog.id);
    setLocation((loc) => ({
      ...loc,
      likes: blog.likes + 1,
    }));
  };

  const likeBlogPost = async (id) => {
    // Fetch call to update the blog post in the server.
  };

  return <span onClick={handleClick}>Likes: {blog.likes}</span>;
}

When you click on the like button, a call is made to the server to update the like count and then setLocation is called. This is an experimental API provided by the React team to mimic a call to the server to fetch a unit of the UI. In this case, we are fetching the component tree for the current route. You can see in the network tab that a call was indeed made and all the components in the current route beginning from the root are returned.

The entire tree is rendered from the root and the parts that are updated are rendered, in this case, wherever likes is displayed on the screen. Note that the call to update was made from the LikeButton component however since the entire tree is updated the likes count passed as a prop to the LikeButton is updated.

State of the Client components are maintained

Let's create a new Comment component, that renders an input text field bound to a state variable. For simplicity, we will not implement the comment functionality.

// Comment.client.js - A Client component.

import React from 'react';

export default function Comment() {
  const [comment, setComment] = React.useState('');
  return (
    <input
      value={comment}
      onChange={({target: {value}}) => setComment(value)}
    />
  );
}

Type something in the comment text field of one of the blog posts. Now, click on any of the like buttons. You can see that even though the entire tree was rendered as a result of the like count update, the state of the Client components are preserved during such updates. As a result, whatever you typed in the comment box is intact and is not cleared. This is one of the biggest advantages of the Server components and a primary difference from traditional SSR.

Client Components

Client components are the components that we having been using all this while. But with server components in the mix, you need to remember one thing,

A Client component cannot import a server component however, it can render a server component passed in as children from a server component. Note that these props should be serializable, JSX is serializable and hence it can be passed in.

Not Possible

// FancyBlogPost.client.js - A Client component.
import React from 'react';
import BlogPost from './BlogPost.server';

export default function FancyBlogPost({ blog }) {
  return (
    <div className="fancyEffects">
      <BlogPost blog={blog} /> // Not OK. Cannot import a Server component inside a Client component.
    </div>
  );
}

// BlogPostList.server.js - A Server component.
import {getBlogPosts} from './blog/blog-api';
import BlogPost from './BlogPost.server';

export default function BlogPostsList() {
  const blogs = getBlogPosts();
  return (
    <>
      {blogs.map((blog) => (
        <FancyBlogPost blog={blog}>
      ))}
    </>
  );
}

The reasoning is quite simple, Client components are sent to the client. If it were to contain a Server component accessing some internal API, that would fail in the client since it will not have access. This is just one reason among many.

Instead, we can do the following.

Possible

// FancyBlogPost.client.js - A Client component.
export default function FancyBlogPost({ children }) {
  return (
    <div className="fancyEffects">
      { children }
    </div>
  );
}

// BlogPostList.server.js - A Server component.
export default function BlogPostsList() {
  const blogs = getBlogPosts();
  return (
    <>
      {blogs.map((blog) => (
        <FancyBlogPost>
          <BlogPost blog={blog} /> // Fine. Server component passed as childredn to a Client component.
        </FancyBlogPost>
      ))}
    </>
  );
}

This is fine because from the perspective of the Client component the content is already rendered in the server as part of the parent Server component and only the rendered content is passed as a prop to the Client component.

Other things to remember with respect to Client components,

They end with the extension *.client.{js,jsx,ts,tsx} (At least for now)
They will be part of the client bundle and as such, you shouldn't be doing anything that you wouldn't want to be public. Eg: DB operations etc.
They are free to use state and effect hooks.
Use browser only API's.

Shared Components

Shared components can be rendered either as a Server component or as a Client component. This is determined by what component imports it. Since it can be used either as a Server or a Client component it has the most limitations.

They don't have a specific suffix.
They cannot have state.
They cannot make use of useEffect etc.
They cannot render Server components.
They cannot use browser specific API's.

With all these limitations, these components can only be used to display content that is passed as a prop to it.

Thoughts and Conclusion

After reading this, if you are thinking that Server components are doing exactly what NextJS/SSR is doing. No. In the case of NextJS, the components are rendered in the server, yes, but eventually, the components are part of the client bundle and used for hydration. In addition, Server components allow for,

Maintaining Client component state.
A much granular integration of Client and Server components. For example, in NextJS, you are limited by pages to choose between client and server components.
Code splitting is done based on file names and is now not an extra step to be done by the developers as an import.

Of course, there are parts that are being worked on like routing and stuff but I am genuinely excited by what Server components bring to the table. They provide the developers with the flexibility to choose between Client and Server components based on the requirements and get the best of both worlds.

Hope, I was able to explain some of the concepts in a way that was easy to grasp. Happy coding and see you in the next one.. :)

Follow me on Twitter or check out my website to know more about me..✨

Typescript Quirks - String or string? Which one should I use?

Dinesh Balaji — Thu, 17 Dec 2020 14:36:38 +0000

If you've been using Typescript, you would have definitely come across string and String. Have you ever wondered which one you should be using? You might have used them interchangeably and they do work. In fact, there are other types like this, Number and Boolean. So what are the differences between the two string types and which one should you be using in your projects? Let's find out.

Let's have a look at a simple example of how you create strings using string and String in Typescript.



const str = "This is my string";
const strUsingString = new String("This is my string");

The first and most basic difference between the two is that string is a primitive type whereas String is an Object type. Okay, so what are the implications of this tiny difference?

Your `typeof` checks will fail

Let's look at an example.



const str = "This is my string";
const strUsingString = new String("This is my string");

console.log(typeof str); // Prints "string".
console.log(typeof strUsingString); // Prints "object"!

As you can see, the typeof operator when used on a string created using String returns object! This means that you no longer will be able to rely on typeof checks to differentiate between objects and strings. If you have checks based on this assumption, they will now fail!

Your equality checks will fail



const str = "Hi";
const strUsingString = new String("Hi");

console.log(str == "Hi"); // Prints true. Good.
console.log(str === "Hi"); // Prints true. Good.

console.log(strUsingString == "Hi"); // Prints true. Good.
console.log(strUsingString === "Hi"); // Prints false. Wait, what?

console.log(str == strUsingString); // Prints true.
console.log(str === strUsingString); // Prints false. Are you kidding!!!

Here, the equality checks using the === operators fail because === not only checks for equality in value but also for equality in type as well. Therefore, even though str and strUsingString have the same value "Hi", str is of type string whereas strUsingString is of type object and hence the check fails. This will lead to bugs which are very hard to debug.

Value vs Reference

When you create a string as a literal, no matter how many of them you create, they will all point to the same literal in storage. However, when you create a string using String, each one creates a brand new object.

Let's look at how the following code is represented in memory.



const str1 = "Hi"; 
const str2 = "Hi";

const strO1 = new String("Hi");
const strO2 = new String("Hi");

Now, consider the following snippet,



console.log(str1 == str2); // Prints true. Good.
console.log(str1 === str2); // Prints true. Good.

console.log(strO1 == strO2); // false. Worse!
console.log(strO1 === strO2); // false. Even Worse!!

This time both the == and === checks fail. This is because what is being actually compared is the address of the memory locations and not the actual value themselves.

This is a pretty big source of bugs! Just imagine trying to compare two strings and you get false in spite of them having the same value.

Conclusion

Always use the lowercase versions, string, number and boolean. This will ensure that you do not run into the bugs mentioned above and since the bugs happen at run time, they are very hard to debug.

Hope you learnt something new. Happy coding and see you in the next one.. :)

Follow me on Twitter or check out my website to know more about me..✨

Story of how I built my Portfolio and Blog using DEV.to and NextJS

Dinesh Balaji — Fri, 13 Nov 2020 16:07:47 +0000

I've always wanted to build my very own portfolio website and blog. After many years of laziness..😋, finally, I mean, FINALLY I've done it..🎉 I have built my own website dineshbalaji.in..✨ Please do check out the website and let me know your thoughts in the comments..🙏

The idea behind this post is to tell the story of how I did it, the tech involved, what I learned along the way and most importantly to inspire many more people (lazy like me may be..:D) to build their own website.

Ground Rules

These are some of the ground rules that I laid down for myself for developing the website.

It had to coded out by me from scratch without using WYSWYG editors.
A good logo.
I have to learn new stuff as I build it.
Minimize usage of third-party libraries.
It has to showcase my coding skills.
Good Lighthouse Score - Performance and Accessiblity.
Has to integrate with a CMS for blogging.
Good SEO.
Be open sourced for others to use/learn.
A full-page canvas landing page..😍 I love them..❤️

The Start

With the ground rules set, I began on October 3rd, 2020. One thing I wanted to absolutely make sure was to track my progress. I've tried building my site a couple of times earlier but I got sidetracked. I was also inspired by this. The way he wrote down whatever little progress he made was the way to go for me. So I did a CHANGELOG. Easy to generate and maintain.

Design

I'm a coder by profession but I do love to design and I'm quite crafty with Sketch. But sticking to my ground rules, Figma, was the first thing I learned. I spent a weekend going through tutorials learning the tool and then went about creating a design system and the website.

The Logo

I had to do a logo for branding. I wanted it to be simple and animatable. I'm happy with what I ended up with.

Being a developer staring endlessly at the screens, I love dark themes and decided to go with it. Chose a couple of popping colors and some shades using crispedge and voila I had my recipe.. 🦄

Fonts

I created the screens over a week. I made sure all the screens were complete before starting development to ensure there were no stoppages.

Technology

Since I wanted a blog along with the portfolio, SEO was of paramount importance and the best way to do that is to build static sites. I wanted to learn React along the way and there were two choices, NextJS and Gatsby. Gatsby was purely static and NextJS provided the flexibility to switch between static and dynamic based on our need. So I ended up with Next JS.

Hosting

Choosing NextJS came with a benefit. The amazing hosting platform from the team that developed NextJS, Vercel. It has first-class tooling to host your website in minutes and has seamless integration with Github for development, preview and production deployments.

I don't want to bore you guys with a long explanation of each and every detail. I'll just list the tech I used on the website with one-liners.

Base Tech

NextJS - The base React framework on which the website is built. It allows you to choose between SSR, SSG and CSR.
DEV.to API - My CMS.. 😋 I love DEV.to as a platform for developer blogging and I didn't want to leave it. But at the same time, I wanted a single source of truth for my articles. So I made use of the dev.to API. It's sweet and I got the best of both worlds.
TailwindCSS with SCSS - I was so happy to have come across TailwindCSS. I strongly recommend this to anyone. Integrating it with SCSS was a pain but if you just use CSS, please try it out.
Typescript - Must have for anyone doing frontend development in 2020.

Tooling

stylelint - For linting CSS, sorting and ordering CSS rules. Must have.
eslint - For linting Typescript code. Must have.
postcss - For CSS browser vendor pre-fixes, purging of unused TailwindCSS rules.
husky - For running linting, commit rules before committing code.
commitzen - Provides a format to your git commit messages. The beautiful change log you saw earlier was possible because of this.
prettier - Standard for 2020. Does what it says, formats and makes your code look beautiful..😋

NPM Packages

framer-motion - All the beautiful animations on the site are powered by this amazing library. You just have to come up with the animations and leave the rest to framer. Highly recommend this one.
react-copy-to-clipboard - For copying code snippets to your clipboard.
react-infinite-scroll-component - For loading content on scroll in posts and nuggets page.
react-intersection-observer - For detecting if elements are scrolled into view.
react-markdown - For parsing the markdown from DEV.to API's and rendering as HTML.
react-syntax-highlighter - Plugin for react-markdown that highlights code within the markdown.
react-share - Provides social sharing icons and functionality for posts and nuggets.
reading-time - Estimates the reading time of a given text.
sitemap - For generating the site's sitemap.xml for SEO.
camelcase - For converting hyphenated strings to camelcase strings.
@svgr/cli - For optimizing and converting SVG's into React components.

Analytics

Google Analytics - I'm using it as my data store for posts view count and also for user demographics and content relevancy.
MS Clarity - This just came out and I really like the heat maps and session playback features they offer.

Development

I am employed full-time so I had to find the time to develop. Most of the website was built over weekends, late nights and early mornings. I used libraries whenever I felt like I was re-inventing the wheel and stuck to coding stuff out when I wanted to showcase my skills.

Particularly, I wanted to ensure that all the canvas-based animations were coded out entirely by me without the use of third party libraries. As a result, I learnt a lot of math and ended up creating mini-libraries Vector.js, Particle.js for the animations on the canvas..👻

Conclusion

After a month of development, I've done it. I'm really happy with the outcome. This is a lighthouse snapshot of my website.

As you can see, it's green across the board..🍾

I intend to add features to the website as I go along and more importantly I hope that this inspires me to blog more.

I also wanna thank Sowmya and Rashmi for their kind reviews and feedback and the Open Source Community in general for all the amazing libraries and tools..🙏

The source for the website is completely Open Sourced.

I sincerely hope that someone reads this and starts their own journey towards building their very own website.

See you in the next one. Peace.. :)

Understanding HTML Form Encoding: URL Encoded and Multipart Forms

Dinesh Balaji — Sat, 11 Aug 2018 14:14:03 +0000

The other day I was trying to write a REST endpoint in Go, which uploads the contents of a form submitted in a browser to another REST endpoint, in other words,

Form in Browser ----> My GO Rest API ----> Another REST API

While doing that I ended up learning some fundamentals of how HTML forms work. So thought it might be a good thing to share what I learned and hence the post.. :)

The encoding type of a form is determined by the attribute enctype. It can have three values,

application/x-www-form-urlencoded - Represents a URL encoded form. This is the default value if enctype attribute is not set to anything.
multipart/form-data - Represents a Multipart form. This type of form is used when the user wants to upload files
text/plain - A new form type introduced in HTML5, that as the name suggests, simply sends the data without any encoding

Now, let us look at each form type with an example to understand them better.

URL Encoded Form

As the name suggests, the data that is submitted using this type of form is URL endcoded. Take the following form,

<form action="/urlencoded?firstname=sid&lastname=sloth" method="POST" enctype="application/x-www-form-urlencoded">
    <input type="text" name="username" value="sidthesloth"/>
    <input type="text" name="password" value="slothsecret"/>
    <input type="submit" value="Submit" />
</form>

Here, you can see that the form is submitted to the server using a POST request, this means that it has a body. But how is the body formatted? It is URL encoded. Basically, a long string of (name, value) pairs are created. Each (name, value) pair is separated from one another by a & (ampersand) sign, and for each (name, value) pair, the name is separated from the value by an = (equals) sign, like say,

key1=value1&key2=value2

For the above form, it would be,
username=sidthesloth&password=slothsecret

Also, notice that we have some query parameters passed in the action URL, /urlencoded?firstname=sid&lastname=sloth.

Don't the URL encoded body and the query parameters passed in the action URL look awfully similar? It's because they are similar. They share the same format discussed above.

Try creating an HTML file with the above code and see how it's submitted in the dev tools. Here is a snap,

The things to notice here are the Content-Type header which says application/x-www-form-urlencoded, the query string and the form fields are transferred to the server in the format as discussed above.

Note: Don't get confused by the term Form Data in the screen shot. It's just how Google Chrome represents form fields.

All is fine, but there is a little more to the encoding process. Let's introduce some spaces in the submitted values, take the below form which is the same as the previous one but has the firstname value changed from sid to sid slayer and username value changed from sidthesloth to sid the sloth.

<form action="/urlencoded?firstname=sid slayer&lastname=sloth" method="POST" enctype="application/x-www-form-urlencoded">
    <input type="text" name="username" value="sid the sloth"/>
    <input type="text" name="password" value="slothsecret"/>
    <input type="submit" value="Submit" />
</form>

Now try to submit the form and see how the form fields are transferred in the dev tools. Here is a dev tools snap in Chrome.

Clearly, you can see that the spaces are replaced by either '%20' or '+'. This is done for both the query parameters and the form body.

Read this to understand when + and %20 can be used. This encompasses the URL encoding process.

Multipart Forms

Multipart forms are generally used in contexts where the user needs files to be uploaded to the server. However, we'll just focus on simple text field based forms, as is it enough to understand how they work.

To convert the above form into a multipart form all you have to do is to change the enctype attribute of the form tag from application/x-www-form-urlencoded to multipart/form-data.

<form action="/multipart?firstname=sid slayer&lastname=sloth" method="POST" enctype="multipart/form-data">
    <input type="text" name="username" value="sid the sloth"/>
    <input type="text" name="password" value="slothsecret"/>
    <input type="submit" value="Submit" />
</form>

Let's go ahead and submit it and see how it appears in the dev tools.

There are the two things to notice here, the Content-Type header and the payload of the form request. Let's go through them one by one.

Content-Type Header

The value of the Content-Type header is obviously multipart/form-data. But it also has another value, boundary. The value for this in the example above is generated by the browser, but the user can very well define it as well, say for example, boundary=sidtheslothboundary. We'll get to see how it's useful in the next section.

Request Body

The request payload contains the form fields themselves. Each (name, value) pair is converted into a MIME message part of the following format,

--<<boundary_value>>
Content-Disposition: form-data; name="<<field_name>>"

<<field_value>>

The above format is repeated for each (name, value) pair.

Finally, the entire payload is terminated by the boundary value suffixed with a --. So the entire request looks like,

--<<boundary_value>>
Content-Disposition: form-data; name="<<field_name>>"

<<field_value>>
--<<boundary_value>>
Content-Disposition: form-data; name="<<field_name>>"

<<field_value>>
--<<boundary_value>>--

Now, we see how the boundary value is used.

In the case of an application/x-www-form-urlencoded form, the & ampersand kind of acts as a delimiter between each (name, value) pair, enabling the server to understand when and where a parameter value starts and ends.

username=sidthelsloth&password=slothsecret

In the case of a multipart/form-data form, the boundary value serves this purpose. Say if the boundary value was XXX, the request payload would look like,

--XXX
Content-Disposition: form-data; name="username"

sidthesloth
--XXX
Content-Disposition: form-data; name="password"

slothsecret
--XXX--

The hyphens themselves are not part of the boundary value but rather needed as part of the request format. The Content-Type header for the above request would be,

Content-Type: multipart/form-data; boundary=XXX

This allows the browser to understand, when and where each field starts and ends.

Text/plain Forms

These forms are pretty much the same as the URL encoded forms, except that the form fields are not URL encoded when sent to the server. These are not used widely in general, but they have been introduced as a part of the HTML 5 specification.

Avoid using them as they meant for human understanding and not for machines.

As quoted from the spec,

Payloads using the text/plain format are intended to be human readable. They are not reliably interpretable by computer, as the format is ambiguous (for example, there is no way to distinguish a literal newline in a value from the newline at
the end of the value).

Hope, I was clear in explaining what I learnt..See you in the next one guys..Peace.. :)

Get to know more about me on my website..✨

Forem: Dinesh Balaji

React - Server Components - Introduction and Initial Thoughts

Server Components

Zero Bundle Size

Render Format

State and difference from SSR

State Tree

State of the Client components are maintained

Client Components

Not Possible

Possible

Shared Components

Thoughts and Conclusion

Typescript Quirks - String or string? Which one should I use?

Your typeof checks will fail

Your equality checks will fail

Value vs Reference

Conclusion

Story of how I built my Portfolio and Blog using DEV.to and NextJS

Ground Rules

The Start

Design

The Logo

Fonts

Technology

Hosting

Base Tech

Tooling

NPM Packages

Analytics

Development

Conclusion

Understanding HTML Form Encoding: URL Encoded and Multipart Forms

URL Encoded Form

Multipart Forms

Content-Type Header

Request Body

Text/plain Forms

Your `typeof` checks will fail