DEV Community: Simon Ström

Super simple communication between tabs, windows or iframes

Simon Ström — Mon, 08 Feb 2021 21:29:05 +0000

At the time of writing this is not supported in Safari browsers. This code example uses this polifill, it offers partial support.

So, you have your web app running. The user opens it multiple times, in tabs or windows, or you might have several iframes on the same page, like the example below. Now you want to send data, events, or any other information across them. How do you do? Well, the answer is actually really simple...

Enter `BrodacastChannel`

All you have to create is a BroadcastChannel instance:

const channel = new BroadcastChannel('test')

It only needs one parameter, the name of the channel. So in any other web app or piece of code you can create a connection by creating a new channel with the same name.

Note that the applications must be under the same origin. For example the same domain name, scheme (HTTP/HTTPS), and port.

Now you need to do two things:

Subscribe to messages
Send messages

So to subscribe, you need an event handler for the onmessage event:

channel.onmessage = e => {
  const { data } = e
  /* The code above is the same as:
   const data = e.data
   and uses a feature called object destructruring
  */
  console.log(data)
}

The onmessage handler will receive the event payload, and the most interesting property would be the data sent. That is what is sent from another tab, frame, iframe, or window. Now look at how we send some data:

channel.postMessage('Hello!!!')

Just use the postMessage function on your channel.

Now we send a simple string message to every other listener. Running the code above in one tab would look like this in another console: Hello!!!

The data you can send is not limited to strings. You can send objects as well.

To close a channel you can call the close method, so it stops listening and can be garbage collected:

channel.close()

Below is a simple demo where you can change the background gradient in both iframes by clicking any button in either one of them:

Reuse the channel

If you want to reuse the channel you might do it by sending actions across like you handle actions using a reducer/redux. Example:


channel.onmessage = e => {
  const { data } = e

  switch(e.action) {
    case "ACTION_1":
      doActionOne(e.payload)
      return
    /* etc. */
  }
}

And dispatching like this

channel.postMessage({
  type: "ACTION_1",
  payload: 42
})

Summary

This is a really simple way to handle events across your application instances or different applications under the same domain. It might be session-/user information or any other data you want to broadcast. One day it might be working across all browsers without polyfill as well...

More information can be found here in the MDN docs

Cover photo by erica steeves on Unspash

Up and running with streams for performance and fun

Simon Ström — Sun, 31 Jan 2021 21:20:25 +0000

One concept that you probably should familiarize yourself with is streams. Streams of data, that you either write, read, both, or transform. It is a really powerful tool in several ways, and I really enjoy using them in my Node code for several reasons. But keep in mind, although we will be using Node this is not in any way specific to Node. Data streams are equally important to use within any programming language.

This will not be super in-depth with advanced topics, but rather a high-level introduction to get you started with streams. Shall we go?

What is a stream?

Although I do not refer to streams as a streaming service, like Youtube or Netflix, these services actually use streams and are the perfect example for a beginner to start to understand what a stream is.

Take Netflix for example: when you click the button to play, the movie starts almost immediately. You don't need to sit and wait for the entire movie to be downloaded before it starts. Like you can imagine any anyone had to do before streaming services were a thing and people downloaded movies (so I heard they did at least).

This concept can, and when applicable should, be taken to your code. At least at any time, you can process the data before it is fully loaded. This can be: file parsing, converting, zipping, cryptography, or HTTP requests/responses.

Different type of streams

There are four different types of streams:

Readable: Well, they read data.
Writable: And yes, they write data.
Duplex: They both read and write data (like web sockets if you are familiar)
Transform: They are used to transform a stream of data before sending it forward. (They are actually duplex streams)

We will explore readable, writable, and transforms using a text file as our input data.

Readable and writable

Let us start with a readable and writable stream. The text file contains a data tab-separated, we simply want to transform this to a comma-separated file.

We can start with a stream that reads the data from the file:

import { createReadStream } from "fs"
const readableStream = createReadStream("./my-input-file.txt", "UTF-8")
readableStream.on("data", chunk => {
  /* TODO: Process input data */
})

It is actually straight forward, create a stream and attach an event listener to capture data. The data will be delivered in small bits and pieces, usually called chunks, and we can write our own function to process it.

One technical importance of readable streams is that they can have two modes paused and flowing.

When we add a "data" event listener the stream enters flowing mode, meaning the data will get to our code automatically as fast as the readable stream works. The paused mode will force you to request data from the stream using the read method of the stream to call for more data.

You can also move between these states but let us not get too in depth.

Let us continue with a write stream so we can transform our data and output it to disk:

import { createWriteStream } from "fs"
const writableStream = createWriteStream("./my-output-file.txt", "UTF-8")

It is pretty much the same procedure to instantiate it. Lets use the writableStream to write the transformed data:

import { createWriteStream, createReadStream } from "fs"
const readableStream = createReadStream("./my-input-file.txt", "UTF-8")
const writableStream = createWriteStream("./my-output-file.txt", "UTF-8")
readableStream.on("data", chunk => {
  writeableStream.write(chunk.replaceAll("\t", ","))
})

That is pretty much it to get started with reading and write streams.

Transforms and pipes

But hey! In the list of available stream types, there is a transform that should be used to transform the input stream and send it to another stream. Yep, that is correct. Let's have a look at that.

A transform can be far more complex than this, we will implement the least code needed for our use case:

import { Transform } from "stream"

const tabToCommaTransform = new Transform({
  decodeString: false,
  transform(chunk, encoding, callback) {
    this.push(chunk.replaceAll("\t", ","))
    callback()
  }
})

We create a new Transform object, and the actual transformation is implemented in the transform function property of that object. The input parameters will be a chunk, the data encoding, and a callback function to invoke when you are done. To pipe data forward you use the push method of the transform using this.push(data) and the data as a parameter.

The decodeString parameter ensures that the data will be kept as a string and not converted into a buffer.

But how do we use it? Now we have three streams that will do the work, a readable, a transform, and a writable. Enter pipes. With pipes you can chain several streams to produce your output, like this:

import { Transform } from "stream"
import { createWriteStream, createReadStream } from "fs"

const readableStream = createReadStream("./my-input-file.txt", "UTF-8")
const writableStream = createWriteStream("./my-output-file.txt", "UTF-8")
const tabToCommaTransform = new Transform({/**/})

readableStream.pipe(tabToCommaTransform).pipe(writableStream)

Now the data will automatically flow from the readable stream through our transform and out the writable stream. Great! There is actually a little nicer way to compose streams using the pipeline utility:

import { Transform, pipeline } from "stream"
import { createWriteStream, createReadStream } from "fs"
/* same as above */
pipeline(
  readableStream,
  tabToCommaTransform,
  writableStream,
  (err) => {
    if(err) {
      console.error(err)
      return
    }

    console.log("Conversion pipeline finished)
  }
)

And as of Node 15, there is a promise version:


import { Transform } from "stream"
import { pipeline } from "stream/promises"
import { createWriteStream, createReadStream } from "fs"
/* same as above*/

async function run() {
  await pipeline(
    readableStream,
    tabToCommaTransform,
    writableStream
  )
  console.log("Conversion pipeline finished")
}

run().catch(console.error)

HOLD YOUR HORSES! That code with transforms looks way more complicated than the first one. And yes that might be true. But what transform streams and pipes make possible is a whole other level of composability. And we will soon talk more about that...

The benefits

First, and foremost: PERFORMANCE. In several ways, but most important your application will be more memory efficient. Take this example, solving the same problem, for example:

import { readFile, writeFile, read } from "fs"
import { promisify } from "util"

const _readFile = promisify(readFile)
const _writeFile = promisify(writeFile)

async function convertData() {
  const data = await _readFile("./my-input-file.txt", "UTF-8")
  await _writeFile("./my-output-file.txt", data.replaceAll("\t", ","), "UTF-8")

  console.log("Conversion succesful")
}

convertData().catch(console.error)

How will this behave differently from our previous code? Well, for this code to work we will have to open the entire file before we can process the data. And then we will replace the tabs in that entire file. So, this code will consume a lot more memory. With streams, as we stated before, we will transform the file in chunks, piece by piece. That also means that we can transform files bigger than our available memory since we never need to keep the entire content in memory at the same time.

Another thing is the responsiveness of our application. If we want to run this code as a response to a web request, besides the memory consumption, the user will have to wait for us to load the file before we can send it. With streams, we can start the transfer as we read the file.

The other benefit, I already mentioned, is the way streams and especially transforms make our code composable. We can change the implementation and add features easily. Let's look at some included features that play well with our file stream and how easy we can add file compression and encryption to this example.

To pipe some file compression we just need to add this line to our pipeline

import { createBrotliCompress } from "zlib"
/* same as above  */
async function run() {
  const compress = createBrotliCompress()
  await pipeline(
    readableStream,
    tabToCommaTransform,
    compress,
    writableStream
  )
  console.log("Conversion pipeline finished")
}

run().catch(console.error)

You could also use the createGzip function exported from zlib to create a Gzip compression.

The encryption part is a bit more complicated since creating a crypto stream requires a few parameters, I will just use some example from the Node docs and promisify that a bit so we get the idea:

import { createCipheriv, randomFill, scrypt } from "crypto";
import { promisify } from "util";

const password = "secret"; //should be better
const salt = "salt"; // should probably be random and better
const _scrypt = promisify(scrypt);
const _randomFill = promisify(randomFill);

async function createEnpryptionStream() {
  const key = await _scrypt(password, salt, 24);
  const initializationVector = await _randomFill(new Uint8Array(16));
  return createCipheriv("aes-192-cbc", key, initializationVector);
}

And then we can just pipe that into our existing pipeline:

async function run() {
  const compress = createBrotliCompress()
  const encrypt = await createEnpryptionStream()
  await pipeline(
    readableStream,
    tabToCommaTransform,
    compress,
    createEncryptionStream,
    writableStream
  )
  console.log("Conversion pipeline finished")
}

run().catch(console.error)

Well, I think you get the idea now how streams make everything composable. Look at the pipeline and you will immediately get a high-level overview of what is happening here. And we can make changes, add and remove features without editing other pieces of code.

As with any abstractions in code, you should of course consider when to use a transform. They do add a bit of extra complexity, and for some one-off scripts, you might not need them.

Summary

So, streams are efficient and composable. Two words I really enjoy hearing when it comes to code. That is why I think streams are so fun and important to use.

Actually, I had not had my job if I did not know about streams. My work test was to build something that parses and sorts more data than available memory. At that time I did write most of my code in C#, but I must say streams in Node is really more of my cup of tea.

Please share if you have any thoughts on this or other resources with streams you find interesting!

Photo by Pietro Jeng on Unsplash

Intro to User Experience

Simon Ström — Tue, 10 Nov 2020 21:02:59 +0000

First and foremost, I am a Software developer not a user experience designer or expert. These ideas are part of a User Experience and product development course I did earlier this year and experience from my time working as a product manager, and of course developer making products.

This article will just scratch the surface of UX, and try to focus on what aspects of the process a software developer would need and want input on.

This article will only focus on the UX process and not take into account how you as a business select features for development. You should of course not only listen to your users, but you must also do development that is aligned with your own business goals. But that is for other departments to decide on, right?

Why should I care about this?

Well, that is a good question actually. You, and me, are probably a busy developer trying to keep up the tech scene, or trying to break into it. Heck, are you into JavaScript? It is a fast-paced world, we are missing out on at least one new UI-framework as we read this!

But consider this. You are faced with the challenge to, with your awesome colleagues, develop a new app. You perfect everything, making the most awesome, good looking, most performant, best-tested app. But none of that matters if your product does not solve a user or business need. Or if your users do not understand how to use your product.

Sure, if you are part of a big company you have people that are responsible for this. They do it all, and you just implement the features. But, many of us do not have this kind of luxury, we might be taking on projects as solo developers.

If you want to build products that are good for your users, you must understand your users. And products that are good for your users will succeed. After that, we should add all the sprinkles and cherries on top to really make it stand out in the competition.

And this can be applicable to developers of all types more or less. For example, if you handle database optimizations, understanding what data is important for your users is required to optimize it correctly.

For a long time I just thought that "building products and interfaces that I like" is a good idea. But that might be a terrible idea if I am not anything like my users.

What is User Experice

User experience, or UX for short, is a wast topic. Covering methods, ideas, and models to build products or experiences that your users, or the users you want to attract, actually needs and wants to use. In a way that they actually can use it, hopefully with ease and joy. Puh... that is a bit.

What we need to know is that UX-design and UI-design are not the same. UX is not about colors, spacing, fonts, or that type of detail. UX is about the greater picture. About how your product should solve some problems for your users. And how to make sure your users can understand and interact with your product.

The basic of the UX process is a three-step method, that is repeated until you are ready for development. Yes, this should proceed the development process in the beginning. And Every iteration should refine the ideas, going from something low fi, like sketches, to something more elaborate, like a prototype.

UX is applicable to all product design processes, but as you might figure out we will think in terms of software/web development from now on. And whenever I write users you could actually change that to "the users you want".

1 - Discovery

The first part of the process is the discovery step. In this step, you research what is it your users actually need? Why do they need it? In what context are they using your application? Etc.

There is a couple of ways to figure this out, but the best ones can be summarized with: talk to your users. Interview them, but do not ask them "what do you want".

Or if you have an existing feature that will be renewed or improved, watch them use the current feature and ask them to speak out their thoughts and intents. What problem are they solving by using this feature?

How many users should you talk to? No idea, but if you talk to one single user, you will at least have one insight over zero. But if you could, talk to some and when you see the same feedback return over and over again you can stop.

Us developers might never take part in this step, but we could ask the ones doing this to try to get some valuable insights. These questions might be good to have answered when building a feature or product:

Where will they use the product. Is it on a mobile, tablet, desktop?

We all hear mobile-first, but in my opinion, it should only ever be mobile-first if our users are mobile-first!

Are they on the run trying to do something quickly or are they focused and have time to complete.

Should forms be simple with opting into more advanced tasks, or elaborate from the beginning?

What are they doing before or after this task.

We could help them into this feature, or on to the next step or application if we know this.

How experienced are your user with "tech"?

Are we making something that our user actually understands, or are we making it too simple or complex?

But maybe most important, why do they use this? What do they as a business achieve?

At the end of this process, you should summarize and present your findings to your team. This can be done in many ways, but the most important part here is to agree on some common ground for your users, or different types of users. This should be presented to all of the persons involved in product development (sales, marketing, development, management, etc.)

You could of course do research by sending out surveys or something like that. But you will probably not get the "why" into the forms only "what". So you might find some feature is bad but not understand why, and therefore not know how to solve it.

2 - Create

In this step, I believe all departments that are responsible for the development should participate if possible. But developers should definitely be represented.

Now when we have some findings, we can map the findings to the user process. We can imagine a story for our users. First, this happens, then this and after that, we solve their problem which makes them happy by solving their business need. So basically, we have defined what problem we want to solve.

The above, and below, parts are a bit more complex in real life. You should dig into user story mapping to actually have methods on how to outline the user flow on both high level and implementation details, but I will skip that for today.

So it is sketch time. Now, what I learned and tested is something quite scary. Make really rough sketches, with NO details in the beginning. Yes sketches, no Figma or XD here.

With all the participants in the room, and a defined problem to solve, give them all pen and paper. Now draw a grid with 6 frames, like a comic strip, on the paper. Now in only 5 minutes, all should individually draw a solution to the problem in the frames.

The room could of course be virtual 😊

Why 5 minutes? Well, the important thing here is not to be stuck with details. We need to iterate fast and try out several ideas. After 5 minutes, everybody presents their ideas to the group and then its critique. Scary right? Well just give some positive feedback with some points on how you would like to improve the sketch. This process most important factor is the discussions, this will guide us to the solution.

After a round of critique, another drawing round starts. Again 5 minutes, this time you should all steal the good ideas your colleagues made and add them to your existing or new ideas. This process can be repeated a number of times.

When you are done it is time to select your top sketches that should be worked more upon. Try to select some favorites as a group or just let everyone vote for their favorites.

Then one of the participants, like a UI-designer or something, takes all the selected sketches and tries to make some refined work with them. Of course, keeping everyone in the loop.

Why? Well, first of all. Sketches are fast. And the faster you make them the easier you can throw them away (this is important). Imagine having worked on some mockups for several hours, maybe days, and you present and someone says nope. That hurts. Imagine drawing for 5 minutes and someone says nope. Not so bad.

Second, if you get the people deciding on the product drawing some sketches themselves and having discussions early on you will get approval faster in the end.

It can be quite scary to do this in a group, you must be brave and try it out and by repeating this process it will be easier.

"None of us is as smart as all of us". That is the key concept here.

3 - Validate

Now, someone has made finalized sketches and we should validate them. This is done by giving a user a specific task to solve. We should try to have some kind of prototype. Now we could do something like a Figma/Balsamic/XD thing here, but paper sketches should work fine as well.

If this is the first iteration it is fine if they are rough, this is all about validating that your design ideas work: The users you show them to understand your intended flow and are able to complete the tasks you ask them to do.

From experience, I can say you will learn a lot by sitting side by side with someone and ask them to interact with your designs. It can be really hard to not just show them or something like that.

It might be a good idea that someone else validates the designs. If the user knows that you are not the one that made the designs they might just be a bit more honest, and you will not go in some kind of defense mode.

One tip is that if a user gets frustrated and asks "how do I do????" you should just say "how would you like to do?". We are not there to learn the user, we want the design to work on its own or only with the instructions given.

What is important in validating is that you, again, ask your users what they think when you show them different sketches. What are they looking at? What are they thinking? How do they feel? Observe them and take notes about everything. For example how frustrated they are trying to solve a specific task.

But when can I start to code??

Yeah, that is what we all love (me too). Yes, write that sweet code. But that is a time consuming and expensive step in product development. This process is all about that we should know what to do before getting into that details.

Sketches and prototypes are easy to throw away, they are fast to spin up and fast to throw away. But when you start adding code time can fly and changes are more time-consuming. So just be a little patient in the beginning, and you will

Summary

Well, as I said UX is wast and complex. But this is the key process I like to adapt to my projects. And I am a firm believer in just cherry-picking things from the different process and find out what works for you and your team.

If you have any thought, please share in the comments. And if you by any chance live in Sweden, you should definitely check this course out.

Cover photo by NEW DATA SERVICES on Unspash

Use hooks in class components with ease

Simon Ström — Tue, 20 Oct 2020 20:02:26 +0000

The application I develop at work has been in development for a couple of years, meaning a lot of the code and structure is, sadly, built without hooks.

Although, sometimes we want to include new features to the older parts of the application. Features that are written with hooks.

No problem!

While we cannot use a hook inside a class component, we could use one of two patterns for code reuse that works with them: Higher Order Components and Render Props. And make the hook available through one of them.

In the rest of this post a Higher Order Component will be referred to as a HOC to save me some keystrokes...

We can imagine a useTodos() hook that loads a list of Todos, and maybe some other stuff as well, that normally would be used like this:

function TodosPage() {
   const { data, isLoading, error } = useTodos()
   if(isLoading) return <Spinner />
   /* etc. */ 
}

Now let us have a look at how to make this hook available with the two patterns:

HOC

A higher order component is just a function that accepts a component as an argument that will receive some additional props.

function injectTodos(Component) {
  const InjectedTodos = function (props) {
    const todos = useTodos(props);
    return <Component {...props} todos={todos} />;
  };
  return InjectedTodos;
}

So we just make the function, it accepts the Component to enhance with all the todo information. Inside we make a function component that uses the hook and return that.

We name the function to make InjectedTodos appear in the dev tools instead of just returning that straight away, to make debugging easier.

Now we could do:

class TodosPage extends React.Component {
  render() {
    const { data, isLoading, error } = this.props.todos;
    if(isLoading) return <Spinner />;
    /* etc. */
  }
}

export default injectTodos(TodosPage);

Great!

Now on to Render props

A render prop component basically hijacks the children properties, replacing that with a function that give you access to additional data or functions:

function TodosData({children}) {
  const todos = useTodos()
  return children(todos)
}

And now we could put this to use like this:

class TodosPage extends React.Component {
  render() {
    return (
      <TodosData>
        {({isLoading, data, error}) => {
          if(isLoading) return <Spinner />
          /* etc. */
        }
      </TodosData>
    )
  }
}

To the ease part

So with not so many lines of code, we could make hooks available in ye old class components. But, imagine that we have several hooks that we would like to make available. We will kind of write the same wrappers again and again, and again to make the hook available through a render prop or a HOC.

To make this transformation easier we could write ourselves two utility functions to convert a hook to either a HOC or render prop.

So for a HOC:

export function makeHOC(useHook, name) {
  return function (Component) {
    const HOC = function (props) {
      const hookData = useHook(props);
      const hookProps = { [name]: hookData }
      return <Component {...props} {...hookProps} />;
    };

    HOC.displayName = `${name}HOC`;

    return HOC;
  };
}

We simply wrap the code to make a HOC with a function that accepts the hook we want to use and what name the props property will be.

I will forward any props to the hook so you could accept arguments to the hook that way.

Also, we do the naming thing, but this time using the displayName property on our component.

Now to make HOCs of our hooks we simply do this:

const injectTodos = makeHOC(useTodos, "todos")
const injectUsers = makeHOC(useUsers, "users")

And for the render prop:

export function makeRenderProps(useHook, name) {
  const RenderProps = function ({ children, ...rest }) {
    const hookData = useHook(rest);
    return children(hookData);
  };

  if (name) RenderProps.displayName = `${name}RenderProps`;

  return RenderProps;
}

Same here, a function that accepts a hook, and optional name to appear in the dev tools. It will forward every prop, except the children, to the hook.

And the creation of render props components:

const TodosData = makeRenderProps(useTodos, "Todos")
const UsersData = makeRenderProps(useUsers, "Users")

What about hooks that accepts multiple arguments?

Well yes, the above code do have some limitations. If the hook where to need several arguments, not from a single props object, that would not work.

If we were to make the react query library hook useQuery available through a HOC or Render Props? That hook needs two arguments, an ID and a function returning a promise of data, and a third, optional, options argument.

So we could either make a "wrapper" hook that accepts the props and returns the hook with the properties in the right place:

function useWrappedQuery(props) {
  return useQuery(props.queryId, props.queryFn, props.queryOptions)
}

The useWrappedQuery could then be used by our makeHOC and makeRenderProps functions.

Or the makeHOC/makeRenderProps functions could accept an additional, optional argument. A function that returns the arguments of the hook. Like this:

export function makeHOC(useHook, name, convertProps = (props) => [props]) {
  return function (Component) {
    const HOC = function (props) {
      const hookData = useHook(...convertProps(props));
      const hookProps = { [name]: hookData }
      return <Component {...props} {...hookProps} />;
    };

    HOC.displayName = `${name}HOC`;
    return HOC;
  };
}

The convertProps function should return an array that will be spread to arguments in the hook. By the default it will return an array with the props as first, and only, argument. Same as the previous implementation.

Now you could map props from the HOC/RenderProps argument to the hook:

class TodoList extends React.Component { /*...*/ }

const injectQuery = makeHOC(
  useQuery, 
  "query", 
  props => [
    props.queryKey,
    props.queryFn,
    props.queryOptions
  ]
)

export default injectQuery(TodoList)

And use this like this

const queryOptions = {retryDelay: 10000}

<TodoList 
  queryKey="toods"
  queryFn={apiClient.todos.get}
  queryOptions={queryOptions}
/>

Now the TodoList component has hook data available in the props query property.

Or we could also hard code the arguments with this function:

const injectTodosQuery = makeHOC(
  useQuery,
  "todos",
  () => [
    "todos",
    apiClient.todos.get,
    queryOptions
  ]
}

/* etc. */

What ever solution you like to implement there is a way, and possibilities to "use" hooks inside class components.

Photo by Marius Niveri on Unsplash

Make fetch better and your API request methods easier to implement

Simon Ström — Sun, 11 Oct 2020 21:11:32 +0000

In this post, I will share my thought on how I like to structure methods on how to get data from your REST API backend. The idea here is to show the basics of my idea, and then you should add, remove, and adopt the code to your specific needs.

This method will also be useful in what ever framework or platform you are in like React, Angular, Vue, or even NodeJS (with a few polyfills, for example fetch...)!

Oh, and a little heads up. We are going object-oriented programming. So a basic understanding of javascript classes and the fetch api would be good before you keep going.

The end game

In the end, we will be able to request data from our backend like this to assign a users variable:

users = await backend.users.get()

Instead of something like this:

const res = await fetch('/users', {
  headers: {
    Authorization: '********',
    lang: 'en'
  }
})

if(!res.ok) throw new Error(res.statusText)

users = await res.json()

Motivation

So why go through this process? Well, first of all, it will make your code easier to read. You will get all the code from fetch hidden behind explanatory method calls. Like backend.get.users(), that makes sense and is short.

Sure you could extract the logic into a function named getUsers() and make the fetch call in there. But then here is the next benefit: don't repeat your self. Without a good structure for your back end requests, you will definitely repeat your self. Setting authorization and other headers in multiple places, or just to see if the fetch call is ok everywhere...

You could also move this code outside into a library for use in your web apps and Node services without a hassle.

Lets get started

The code can be found here.

So we will start of by making our own "mini, mini, mini version" of Axios (or insert name of http client here):

class HttpClient {
  constructor(options = {}) {
    this._baseURL = options.baseURL || "";
    this._headers = options.headers || {};
  }
}

We start things off with the constructor, we will accept two options when instantiating the class:

Base URL will be used to construct the URL. Later we will use a get method like this get('/users') and if we defined the baseURL with https://jsonplaceholder.typicode.com the request URL will be https://jsonplaceholder.typicode.com/users

Headers will be a default set of headers that will be sent with every request.

If you think, "what is with the _ before property names?" Well, I intend these properties to be private. Meant only to be used inside this (or inherited) classes. Not from anywhere outside in the actual app code. Soon there will be a syntax for this as well that implements the behavior, check this out

We should probably add some way of setting headers as well:

setHeader(key, value) {
    this._headers[key] = value;
    return this;
  }

At the end of the setHeader method I added return this. This is added so we can chain method calls. For example when instantiating the HttpClient class:

const httpClient = new HttpClient({baseURL: 'xxx'})
                     .setBasicAuth("user", "pass")
                     .setHeader("lang", "en")

Now in the example above I used another method setBasicAuth. I will skip that for now, but at the end of this post, you will find some inspiration for more properties and things you can add to the client.

Lets make requests!

This will be done in two steps. First of all we will define our own wrapper function for fetch, and then we will make separate methods for get/post/put/delete/patch:

async _fetchJSON(endpoint, options = {}) {
  const res = await fetch(this._baseURL + endpoint, {
    ...options,
    headers: this._headers
  });

  if (!res.ok) throw new Error(res.statusText);

  if (options.parseResponse !== false && res.status !== 204)
    return res.json();

  return undefined;
}

So this wrapper function just makes fetch behave a little more like I want it to do in this specific use case. Like the fact that fetch does not throw on bad requests.

The first argument is just the endpoint (string), and if we set the baseURL option it will be relative to that.

And the options argument is just the fetch Request object we can add additional properties to. It can be empty, but more information about available properties is found here.

Oh! But I do append the parseResponse options to this argument to tell whether the response should be parsed to JSON or not. For most of my use cases, I want to opt-out of the parsing. So if left blank the parsing is done if not the API explicitly states No Content.

You could argue that we could check the content length or some other stuff, but what is good is that if I do require a response and I say I wanted it parsed. This method will throw if I do not get the response. So it will blow up here instead of in my application later where it might take me longer to find the cause.

Now lets expose some ways of making request. This should hopefully be straight forward:

get(endpoint, options = {}) {
  return this._fetchJSON(
    endpoint, 
    { 
      ...options, 
      method: 'GET' 
    }
  )
}

post(endpoint, body, options = {}) {
  return this._fetchJSON(
    endpoint, 
    {
      ...options, 
      body: JSON.stringify(body), 
      method: 'POST' 
    }
  )
}

delete(endpoint, options = {}) {
  return this._fetchJSON(
    endpoint, 
    {
      parseResponse: false,
      ...options, 
      method: 'DELETE' 
    }
  )
}

/** AND SO ON */

We simply call our _fetchJSON method and set some options to make the HTTP method match our method name, and maybe set a body correct so that is taken care of.

Now we could just do some API calls:

const httpClient = new HttpClient({baseURL: 'https://example.com'})
                     .setHeader('lang', 'sv')

const users = await httpClient.get('/users')

One step further: The API client

We have done a lot! This client is our own "mini, mini, mini-version" of Axios. That we easily can extend with whatever parameters, options, or functions we would need.

But I want to take it one step further, I want to define our back end API with easy to call methods. Like I mentioned in the beginning. Now we can take one of two approaches. We could just add more methods to the HttpClient directly, and keep on working.

But, this class does serve its purpose now, right? It can work on its own, and be useful that way. So what if we let the HttpClient class be our base class and we can inherit that one to create our ApiClient class.

This way we can make other HttpClients for talking to other services by using the HttpClient class directly. And talking to our backend with the ApiClient class, which just adds to the existing functionality.

Inheriting the HttpClient class would look like this:

import HttpClient from "./http-client"

class ApiClient extends HttpClient { 
  constructor(baseURL, langCode) {
    super({
      baseURL,
      headers: {
        lang: langCode
      }
    });
  }

  get users() {
    return {
      get: () => this.get("/users"),
      delete: (id) => this.delete(`/users/${id}`),
      create: (user) => this.post("/users", user),
      update: (user) => this.put(`/users/${user.id}`, user)
    };
  }
}

export default ApiClient

Well, that was quite fast. We just added our little flavor to the constructor and we could simple and quickly define our endpoints.

And adding additional endpoints is now really simple and reliable.

Take it further

Now, this was a quick way to add basic functionality and then extending this to make the specific client.

The idea here is to make the base as simple as possible and then add every feature you need instead of bringing in the full capacity of an external library upfront.

Some things you could do next, if applicable to your needs of course:

Add helpers to authenticate if you do not rely on cookies

For example, if you need basic authentication:

setBasicAuth(username, password) {
  this._headers.Authorization = `Basic ${btoa(`${username}:${password}`)}`
  return this
}

Just remember that btoa is not available globally in NodeJS. But just polyfill it and you will be good to go.

And for a bearer auth:

setBearerAuth(token) {
  this._headers.Authorization = `Bearer ${token}`
  return this
}

Make the functions generic if you are on typescript

I do like typescript, 90% of all my code is in typescript. When building this for typescript add a generic return type to the functions, and for your post methods you should type the expected body:

_fetchJSON<T = any>(endpoint: string, options: RequestInit = {}):Promise<T>{ /**/ }

I usually do a little hack when the body is not parsed and say return undefined as any to just get Typescript to not complain. If you expect undefined T should be undefined and you are good to go.

And in your API client for a post request like this:

users = {
  post: (user:IUser) => this.post<IUser>('/users', user)
}

Add methods to any applicable header your API expects/can use

For example at work we have a header to include or exclude empty values in the response (to save some time transferring large collections)

includeEmptyAndDefault(shouldInclude) {
  if(shouldInclude) {
   this._headers.IncludeEmptyAndDefault = 1
  } else {
   this._headers.IncludeEmptyAndDefault = 0
  }
  return this
}

Build a package

Use Rollup or tsdx, if you are into typescript, if you want to do a separate package. This way the API client can be used as a module in other projects as well. That can be great for you, and your customers, to make things happen fast.

But as I said, only add what you need. If you have any thoughts please share them in the comments and recommend me any patterns you like if this was not your cup of tea.

Cover photo by Florian Krumm on Unsplash

Different return types for same function in Typescript

Simon Ström — Sun, 04 Oct 2020 20:09:31 +0000

Also known as overloaded functions

The idea is that you have a function that accepts different arguments or argument types. And based on what arguments you pass you can have different return types.

The example

This could be used in several ways, as everything, but we will keep it simple (example simple). And get rid of one of those annoying things that typescript cant understand. Look at this function:

function greet(user:IUser | undefined):string | undefined {
  if(!user) return undefined;
  return `Hello ${user.firstName} ${user.lastName}!`
}

We know for sure that when the user is defined we will get the string. Could we tell Typescript this? The short answer is yes!

And here is how

As said, we will overload our function and you can find more info here in the docs.

The syntax might look a bit weird, at least in my opinion. But we can tell Typescript all the different ways we can call the function and what return type is associated with them. Like this:

function greet(user: IUser):string
function greet(user: IUser | undefined):string | undefined

This is our "overloads" of the function that we add before the actual implementation. Now the function looks like this:

function greet(user: IUser):string
function greet(user: IUser | undefined):string | undefined
function greet(user: IUser | undefined):string | undefined {
  if(!user) return undefined;
  return `Hello ${user.firstName} ${user.lastName}!`
}

Or you could just type the actual function with any, that is fine too:

function greet(user: IUser):string
function greet(user: IUser | undefined):string | undefined
function greet(user: any):any {
  if(!user) return undefined;
  return `Hello ${user.firstName} ${user.lastName}!`
}

Now Typescript is aware that when we have a user we will get a string, and when we might have a user. Well we might get a string.

And if you go with the any way of method implementation, you still cannot call the function with any argument. It will have to be IUser or undefined.

You can check the example here

Summary

Yes, this example is a little bit simple. But the idea is that the when we call the function we can be made aware when we need to check for undefined and when we can skip.

It will make the code easier for your colleagues, or future you, to approach. The functions in "real life" will probably be more complex and by giving the return type for different options will make the life easier for everyone. By not having to read the function details to understand when we get type x and when we get type y.

Cover photo by Juan Gomez Unspash

Intro to Typescript generics (a must know)

Simon Ström — Tue, 22 Sep 2020 19:37:57 +0000

Photo by Anas Alshanti (Unsplash)

If you are a Typescript developer and haven't already started using generics, you are missing out! The word itself is quite scary, 🧟generics👻. But fear not, it is really simple and very useful!

What the *!#@ is generics any way?

Since JavaScript is a dynamic language generics is not a thing there. Everything is kind of generic.

You would have go down the road to C#,Java or Tyescript to find definitions and use cases for generics.

Generics are enabling us to create a component that can work over a variety of types rather than a single one. (That line is from the Typescript docs, and you should go there later to really dig deeper...)

When creating a function, for example, some functions would be great if they could work with different types. Or really any type! And that is easy of course, just slap some :any magic there and the function is generic. Right?

Generic functions accept many types while remaining the type info!

One example, please!

The code can be found here

Say we have a simple interface in our game app that looks like this

interface IScore {
    playerName: string;
    kills: number;
    deaths: number;
}

Now we need some way of calculating averages of arrays with objects of this interface. So we write something like this:

function avg(items:IScore[], getter: (t:IScore) => number) {
  const sum = items.reduce((acc, curr) => getter(curr) + acc, 0)
  return sum / items.length
}

Simple, we take an array of scores as the first argument, and the second is a function that will get the number property used to calculate the average.

But this function only works for one type, the IScore. That is not cool, this function could be used with other types as well. As a generic function, so we could do like this, right:

function avg(items:any[], getter: (t:any) => number){/*...*/}

Great, now it works with literally :any type. But, wait. Isn't the whole point of Typescript not to do like this. Dynamic scary things can happen now, what if we remove a property from the interface Cannot read property X of... errors will haunt us when the getter is not finding the property name.

Enter generics (the real type)

To make this function a generic function, and add type checks, we only need to alter the signature of the function. A generic type is annotated with the <> signs before the function arguments. Like this:

function avg<T>(...

The T part is the name of your generic type. This could almost be anything, common (what I have seen at least) is to use T if there is only one type. Yes, T is for Type. You could be more specific, it's encouraged when using multiple generic types in one function like <TFriend, TEnemy>

The next step is to simply replace the :any parts with :T to make the function generic:

function avg<T>(items:T[], getter: (t:T) => number){/*...*/}

Now we could just do something like this

const deathAvg = avg<IScore>(scores, x => x.deaths)

Or even this:

const deathAvg = avg(scores, x => x.deaths)

Typescript will infer the type to use in the generic function, and use that one automatically

Extra credits

While this function could actually use any type given to it (a string array could calculate the average char length of all words) we can for the sake of example restrict this one to only accept arrays of objects. This would be called a constraint on the generic type.

Meaning, the generic type cannot be anything. It must fulfill some rule(s). This information is added to the generic signature with the keyword extends. We say the given type T must extend something. In our example object. So we just change to this:

function avg<T extends object>(items:T[]...

One more example?

You could also make your types generic. A lot of API endpoints response types have the same basic shape. They contain information about the total number of items in the database, response, and if there is more data to fetch. And then of course the list of items. So I could write a type collection for everything like this:

interface IUsersCollection {
  values: IUser[];
  totalInDatabase: number;
  totalInResponse: number;
  isLast: boolean
}

interface IDatabaseCollection {
  values: IDatabase[];
  totalInDatabase: number;
  totalInResponse: number;
  isLast: boolean
}

That is not fun. Not at all. Think only if we add one property to the response...

Simply do this

interface ICollection<TType> {
  values: TType[];
  totalInDatabase: number;
  totalInResponse: number;
  isLast: boolean
}
interface IUsersCollection extends ICollection<IUser> {}

interface IDatabaseCollection extends ICollection<IDatabase> {}

And it works great with type as well:

type Collection<TType> = {
  values: TType[];
  /* etc. */
}

And you could just put your type definition straight there

type UsersCollection = Collection<{
  id: number;
  name: string;
  /* etc.*/
}>

Summary

So generics, saves you time both in making smarter types/interfaces and implementing type safety where you would otherwise just mess around with :any.

And this is not all. Generics can be used in several other fun and useful ways!

Override or set property to React element

Simon Ström — Thu, 17 Sep 2020 19:37:27 +0000

Photo by Thomas Tastet (Unsplash)

So, for a long time I thought when you have created an instance of an component (an element) you had no way of altering it. This was usually a problem for me when building reusable components.

But there is a React helper method for this!

React.cloneElement

The utility I am referring to is the cloneElement function exposed. You can use this to Clone and return a new React element using element as the starting point as stated on the docs.

The function accepts three arguments (one mandatory)

The element to clone (This one is mandatory, of course...)
The props to spread to the cloned element props.
The new children to append to the element. If omitted the original children will remain.

For example lets override the click event and text on an imaginary Button component:


const buttonElement = (
   <button onClick={() => alert('hello')>Click me!</button>
)

React.cloneElement(
   buttonElement, 
   { 
      onClick: () => alert('This replaced the original onClick prop')
   },
   "I am the new text"
)

That is all there is to it really. The cloned element will have all the same props but a new click handler. And the children have been replaces with a new text.

Lets build something

The code for this example can be found here

We will build a popup menu with a list of actions. The consumer will only add regular button or anchor elements as children and we will enhance they all with consistent styling and event handlers to open/close the popup.

First just write a little helper. This piece of code will just ensure the children to be an array so we can use map of it

function toArray(items) {
  if (!items) return [];
  if (Array.isArray(items)) return items;
  return [items];
}

Next up, the component. And it is quite straight forward. Simple state hook to handle the open/closed state const [open, setOpen] = useState(false).

Somewhere in the component we will alter our child components:

{toArray(children).map((c) =>
   React.cloneElement(c, 
      {
         className: "button",
         style: undefined,
         onClick: function (e) {
         setOpen(false);
         c.props.onClick?.(e)
      }
   })
)}

We simply clone the element, override the styles and className property to ensure a consistent styling.

The onClick metod is enhanced, meaning we add our own implementation that closes the menu but also calls the existing onClick method, if it is defined, using optional chaining (hence the question mark)

The full code for the Menu component:

function Menu({ children }) {
  const [open, setOpen] = useState(false);

  return (
    <div className="button-menu">
      <button
        className="menu-toggle"
        aria-controls="menu"
        aria-expanded={open}
        onClick={() => setOpen(!open)}
      >
        {open ? "Close" : "Open"}
      </button>
      <div
        id="menu"
        className="button-group"
        style={{ display: open ? "inherit" : "none" }}
      >
        {/*
        This is the important part
        */}
        {toArray(children).map((c) => {
          return React.cloneElement(c, {
            className: "button",
            style: undefined,
            onClick: function (e) {
              setOpen(false);
              //eslint-disable-next-line
              c.props.onClick?.(e);
            }
          });
        })}
      </div>
    </div>
  );
}

The only quirck with this approach is that you need to set keys for the elements inside the Menu component:

export default function App() {
  return (
    <Menu>
      <button key="a" 
          onClick={() => alert("I am from the button")}
      >
        I am button
      </button>
      <a key="b" href="#something">
        I am an anchor
      </a>
      <div key="c">Divs should not pose as buttons...</div>
    </Menu>
  );
}

Manipulating child state in React, a fun anti-pattern

Simon Ström — Mon, 07 Sep 2020 09:50:29 +0000

Photo by Thomas Tastet (Unsplash)

NOTE: I do recommend using these pieces of code sparse. After all, it is an anti-pattern. And if you are a beginner, you should probably read this on how to change the value of child components by lifting state up first...

How to modify the state of a child component?

As we learn to use React we are told this is not possible, or at least it is not desired. We should lift state up, use context, or composition, or any other pattern to solve this issue.

And while that is the correct way to go about it, sometimes you might just want to "reach down" to your components instead of children reaching up...

And for me, it was a bit of an "aha moment" finding this technique on what is actually possible in React.

Entering refs

When we interact with the real DOM we do this using refs. Refs to other objects maintaning their own "state":

function App() {
  const ref = useRef();

  useEffect(() => {
    ref.current.innerText =
      "I am manupulating the refs 'state'";
  }, []);

  return <div className="App" ref={ref} />;
}

This technique can be used to attach references to your components. And while we interact with "something else" it really feels like we are manipulating the state of our children...

The old faithful counter example

Let us assume we have a self-contained Counter component with a simple state.

function Counter() {
  const [value, setValue] = useState(0);

  function changeValue(factor) {
    return function () {
      setValue(value + factor);
    };
  }

  return (
    <div className="counter-container">
      <button onClick={changeValue(-1)}>-</button>
      <div className="counter-value">{value}</div>
      <button onClick={changeValue(1)}>+</button>
    </div>
  );
}

Now our specifications change and we need to do custom changes to the number from the parent component.

The correct way to go would, of course, is to lift value and the change handlers to the parent component. Then we could let the parent component maintain the state, and thus update the counter component.

But let us not do this. We are going freaky

forwardRef and useImperativeHandle to the rescue

We are using two utils from the React library to solve the issue. First of all forwardRef

This function wraps a component and lets us attach the ref to another child component. This is usually needed in component libraries to attach your ref to the DOM element (like the example above). When wrapping in forwardRef, your component receives two arguments: the first usual props object, and a second (optional) ref, the actual ref object from the parent instantiating the component.

const Counter = forwardRef(function (props, ref) {
...
})

Next up, the useImperativeHandle hook

This hook that (as stated on the docs) "customizes the instance value that is exposed to parent components when using ref". (And also warn us that this is not a good practice... But let us ignore the second part 😊)

Meaning, we can take a ref and attach properties or functions to it. Thus making them available for the parent component instantiating the ref.

What we add to the component is this piece of code:

useImperativeHandle(ref, () => ({
    /** In the imperative handler the change  will 
        immediatly be executed.
    */
    changeValue: (factor) => changeValue(factor)(),
    setValue
  }));

Now the full code for the counter component looks something like this:

const Counter = forwardRef(function (_, ref) {
  const [value, setValue] = useState(0);
  function changeValue(factor) {
    return function () {
      setValue(value + factor);
    };
  }

  useImperativeHandle(ref, () => ({
    /** In the imperative handler, the change  will 
        immediately be executed.
    */
    changeValue: (factor) => changeValue(factor)(),
    setValue
  }));

  return (
    <div className="counter-container">
      <button onClick={changeValue(-1)}>-</button>
      <div className="counter-value">{value}</div>
      <button onClick={changeValue(1)}>+</button>
    </div>
  );
});

Now where ever we use the counter component we can create a ref using the const ref = useRef() method and pass it to the counter component: <Counter ref={ref} />. Where ever we have access to the ref we can execute the functions setValue and changeValue like this:

<button 
  className="wide" 
  onClick={() => ref.current.setValue(2)}
>
  Set counter to 2
</button>

The full code and example can be found here

Summary

As stated, this might not be the best performant or most correct way to solve the original issue. But it is a fun way to explore the possibilities with React. I have only used this with my internal component libraries to access or manipulate some little piece of internal state, where the logic of the component is intended to be self-contained. But then something happens, and you might need to reach for that little piece of state or handler...

DEV Community: Simon Ström

Super simple communication between tabs, windows or iframes

Enter BrodacastChannel

Reuse the channel

Summary

Up and running with streams for performance and fun

What is a stream?

Different type of streams

Readable and writable

Transforms and pipes

The benefits

Summary

Intro to User Experience

Why should I care about this?

What is User Experice

1 - Discovery

2 - Create

3 - Validate

But when can I start to code??

Summary

Use hooks in class components with ease

No problem!

HOC

Now on to Render props

To the ease part

What about hooks that accepts multiple arguments?

Make fetch better and your API request methods easier to implement

The end game

Motivation

Lets get started

Lets make requests!

One step further: The API client

Take it further

Add helpers to authenticate if you do not rely on cookies

Make the functions generic if you are on typescript

Add methods to any applicable header your API expects/can use

Build a package

Different return types for same function in Typescript

Also known as overloaded functions

The example

And here is how

Summary

Intro to Typescript generics (a must know)

What the *!#@ is generics any way?

One example, please!

Enter generics (the real type)

Extra credits

One more example?

Summary

Override or set property to React element

React.cloneElement

Lets build something

Manipulating child state in React, a fun anti-pattern

How to modify the state of a child component?

Entering refs

The old faithful counter example

forwardRef and useImperativeHandle to the rescue

Summary

Enter `BrodacastChannel`