DEV Community: Aki Rautio

Different ways of writing styles in React

Aki Rautio — Sun, 31 Jul 2022 17:54:00 +0000

Writing CSS styles is essential for frontend applications, but CSS doesn't scale well. The lack of namespaces or types makes writing styles for complex applications error-prone. Luckily multiple solutions resolve these issues and work well with React.

All the solutions take a bit different approaches to make CSS easier to maintain and have a different set of features and drawbacks. Thus why selecting a suitable solution will enable you to write better code.

Note: Many of these libraries work with other frontend frameworks too but this article focuses on libraries that work with React.

CSS files

The classical way of writing styles for the React application is to write CSS files and use them with Javascript.

The solutions that use CSS files are rarely limited to React since the concepts are universal and the connection between CSS and React is the class name.

CSS files / Inline CSS

Writing plain CSS files or inline CSS for React doesn't differ much from writing them for HTML files. The greatest difference is that to use className property instead of class.

// File: styles.css

.mainClass {
  border: 1px solid blue;
}
.errorClass {
  border: 1px solid red;
}

// File: App.ts

import 'styles.css';

function App({ error }: AppProps){

  return (
    <div className={error ? "errorClass" : "mainClass"} style={{ color: 'red' }}>Main Activity</div>
  )
}

This is a very barebone way to write CSS and it aligns strongly with the way CSS is used in a normal HTML page. Plain CSS enables an easy way to use the same styles between applications regardless of the framework and the CSS files are usable immediately.

The downsides of using only CSS or inline CSS are the ones we mentioned earlier. Your React code doesn't know whether the particular class name exists and CSS is lacking namespacing so you can easily override the previous class. The whole process of providing CSS is also manual so there is no automated merging or splitting of CSS files.

Using plain CSS files works well for reasonably small websites or applications where complexity doesn't get high and the styles are needed to be shared between different frameworks (or just with HTML). In React I would suggest using CSS files through CSS modules if the build system includes the feature.

SASS / LESS

SASS and LESS are preprocessors for CSS. They offer a programmatical approach to writing styles which will be turned into standard CSS.

Using SASS and LESS works very much the same way as normal CSS and the difference only comes when bundling the code.

// File: styles.scss

$normal-border: blue;
$error-border: red;

.mainClass {
  border: 1px solid $normal-border;
}
.errorClass {
  border: 1px solid $error-border;
}

// File: App.ts

import 'styles.scss';

function App({ error }: AppProps){

  return (
    <div
      className={error ? "errorClass" : "mainClass"}
      style={{ color: 'red' }}
    >
      Main Activity
    </div>
  )
}

The advantage of using either of the preprocessor is that a lot of repetitive styles can be automated (see an example from the common component post). Adding variables or creating iterative loops makes it easy to write more complex classes without writing repetitive content manually.

Since the preprocessor resolves the issue of creating programmatical styles, it might cause even more issues since you can easily use class names in React that do not exist.

I would use SCSS or LESS when there is a need to create programmatical styles (ie. having different class names or having a need to calculate values or colors for the classes). When using a preprocessor, one should someway to test out that the classes exist and work as expected.

CSS modules

CSS modules couple CSS styles more tightly to React and at the same time solves the namespace issue. When a CSS file is imported to React, it will create a namespace for the file.

The import gives an ability to connect the created namespace with the original one by returning an object with original class names as a key.

// File: styles.css

.mainClass {
  border: 1px solid blue;
}
.errorClass {
  border: 1px solid red;
}

// File: App.ts

import styles from 'styles.css';

function App({ error }: AppProps){

  return (
    <div
      className={error ? styles.errorClass : styles.mainClass
      style={{ color: 'red' }}
    >
      Main Activity
    </div>
  )
}

Depending on the connection between React and CSS files allows safer use of class names and makes recognition of the missing classes one step easier than using just plain CSS files. It's also good to note that CSS modules work with any preprocessing library like SASS or LESS.

There are no real drawbacks to using CSS modules as is but it inherits the downsides of writing plain CSS. It naturally lacks the type checks and build-time checks whether the class exists.

Using CSS files with CSS modules protects against complexity which makes it a viable option to use with more complex Javascript applications.

CSS-in-JS

CSS in JS libraries move styles to Javascript files instead of handling them in a separate CSS file. The advantage is to keep all the logic within Javascript instead of splitting the logic between JS and CSS.

Styled components / Emotion

Styled components are one of the first ones that introduced CSS-in-JS and have been one of the most popular ones to use. Emotion is another popular choice.

Both libraries use the styled function that takes an HTML tag and the styles through template literals and returns a React component that creates an HTML element with the generated class name and CSS styles linked to that generated class name.

// File: App.ts

import styled from 'styled-components';

const Content = styled('div')<{ error: boolean }>`
  border: 1px solid ${props => error ? props.theme.errorBorderColor: props.theme.borderColor};
`

function App({ error }: AppProps){
  const theme = {
    mainBorderColor: 'blue',
    errorBorderColor: 'red
  }

  return (
    <ThemeProvider theme={theme}>
      <Content
        error={error}
        style={{ color: 'red' }}
      >
        Main Activity
      </Content>
    </ThemeProvider>
  )
}

The biggest advantage of styled function (and CSS-in-JS in general) is automated naming of classes and handling of CSS files. Using styled functions also gives a lot of freedom to write your style-related logic the way you want (see Common component examples). The styles can be more dynamic and passing specific values to components is easier.

The dynamic behavior of the styled function is also a drawback due complexity of creating static class names. This needs computing power on runtime which may end up leading to slowness. While styled components include server-side rendering, complex styles are still slower to create than static styles.

Styled components and emotion work well with an application that has a lot style related business logic (colors depend on the logic) and it excels more with applications that need dynamic styling.

Vanilla Extract

Vanilla Extract brings CSS-in-JS more to the traditional side. The styles are defined in a typescript file but they are separated from the rest of the application logic. While it also supports passing dynamic content, it's done often by variants and there are no full dynamics. This results that Vanilla Extract can generate styles statically and enable zero runtime need.

// File: styles.css.ts

import { style } from '@vanilla-extract/css';

export const [themeClass, vars] = createTheme({
  color: {
    mainBorder: 'blue'
    errorBorder: 'red'
  },
});

const base = style({
  border: '1px solid'
});

export const mainClass = styleVariants({
  main: [base, { background: vars.color.mainBorder }],
  error: [base, { background: vars.color.errorBorder }],
});

// File: App.ts

import { mainClass } from './styles.css.ts';

function App({ error }: AppProps){

  return (
    <div
      className="${mainClass[error ? 'error' : 'primary']}"
      style={{ color: 'red' }}
    >
      Main Activity
    </div>
  )
}

A big advantage of Vanilla Extract is the type safety that enables autocomplete in VSCode and ensures that CSS is always correct. and eases up selecting the correct option for a style parameter.

Another key feature with Vanilla Extract is generating CSS during build time instead of runtime. This can be either upside or downside depending on how much dynamic styling is needed. Vanilla extract offers using variants so there are some possibilities but they are very limited compared to styled components.

The key drawbacks come from being strictly build-time. The development flow feels a lot more similar to writing plain CSS files than writing CSS-in-JS which might some people. Vanilla Extract also restricts writing some dependent styles (for a good reason) which might cause issues in case the application needs these.

Vanilla Extract works well in applications where the performance is important and styles are only used within React. If the codebase uses Typescript, it would make a lot of sense to use Vanilla Extract instead of CSS files with CSS modules.

Utility libraries like Tailwind CSS

Utility libraries like TailwindCSS reduce the number of CSS styles needed to be written having commonly used styles abstracted to class names and using those class names to define the style of the HTML element. This keeps the class name size small which helps to keep the CSS file small especially when combined with postprocessor which excludes nonexisting class names.

function App({ error }){
  return (
    <div
      className={["border-2","border-solid",error ? "border-red" : "border-blue].join(" ")}
      style={{ color: 'red' }}
    >
      Main Activity
    </div>
  )
}

While this is often seen as a tool to do only rapid prototyping, in my experience they are also usable in a real product, especially when combined with custom styles. Utility styles enable to keep the styling inside Javascript files and still not combine CSS in JS.

The downside of the utility libraries is the naming of the new abstraction layer. Since all styles will be written with the new naming, it takes some time to be efficient. The utility libraries also cover only the usual scenarios which might be limiting.

Utility libraries are somewhat middle ground between CSS-in-JS and plain CSS so they fit well in applications where styles are not handling something very unusual. Application with forms or tables would be a great use case, collaborative drawing application most likely not.

Take control of feature implementation with a refining stage

Aki Rautio — Sun, 04 Jul 2021 17:13:30 +0000

The most valuable features I've ever created were the ones that had a clear objective for their implementation, and the entire team had complete control over their tasks throughout the development process. A well-executed refining stage is a major factor in the rest of the process running smoothly.

When a developer is skilled at refining stories, they're better able to scope features in a way that captures their value in a reasonable and well-estimated time. It's a difficult skill to acquire because the appropriate level of detail differs between features.

When refinement goes wrong

"Let's see what happens when we get there."

I've heard this comment many times in my career as I've worked on technical refinement, and I've said it myself as well. While this is a perfectly appropriate method for performing some less complex tasks, it is a risky approach.

Since this approach means many decisions must be made on the fly, high-level refinement for particularly complex tasks is bound to fail, resulting in poor results and bugs.

Here's such a story from a few years ago. We were in the implementation phase of a feature that we'd promised to deliver within two weeks from the start. During a refinement phase, the feature didn't look too complex, but when I started to implement it, I saw that we'd had missed some complexity, and I needed to design the proper logic for it while coding.

The logic took longer to complete than I had expected, but I was happy—I had built a scalable solution to the problem in a short amount of time. To make up for lost time, I had to accelerate the rest of my work so that I could complete the full feature on time. How did I manage that? Well, I cut corners. I neglected automated testing, just pushing through and hoping that everything would operate correctly when I was done.

Well, I had overlooked several edge cases while developing the logic, so we had to go through two different feature testing cycles before we got it right, and we ended two weeks behind schedule. Inadequate refining was the root cause of all these cascading events.

Taking control of the tasks

From the developer's perspective, successful refinement should provide clarity about what needs to be developed so that during the implementation, the focus is on the details instead of the big picture. In my experience, being able to focus on one single well-defined task at a time gives me the ability to pay attention to details like code readability.

When a developer needs to clarify feature scope or requirements while writing their code, they need to shift their focus between a zoomed-in view of the details they're currently working on and the big picture overview. This is very taxing for the brain and it leads to a feeling of not being in control of one's own tasks. It's important to be able to determine where to focus during each part of the development process.

A well-executed refinement process has a lot of underlying focus points, and it requires all the team members contribute their expertise to the process. Without proper cooperation, it's not possible to get the best results. In my experience, following these principles during the refinement process, and involving developers in this process from the start, will help your team members each retain control over their tasks during the implementation phase.

1. Correct features create customer value

Capturing customer value is a key motivation for investing time and effort to develop a feature. If the same customer value can be captured better with another feature or a different approach, it may be worth altering the feature's requirements.

Since every team member perceives things from their own unique point of view, developers should be the ones to challenge decisions from a technical standpoint. To make this happen, developers should be involved in the refinement process as early as possible.

To be honest, this is one of the most difficult parts of the process for developers to master. It takes a lot of experience to see alternative technical possibilities and identify the pros and cons early on. It's much easier to note them retrospectively. But with practice, developers can provide a lot of added value early in the refinement process.

2. Reasonably sized features help with constant delivery

The size of a feature has a major impact on how well it captures value and how smoothly the development process runs. In my experience, if the feature is too big, refinement either takes a long time or is done at a high enough level that it cannot be executed successfully.

In general, a feature that takes up to a month to deliver by a single developer is able to capture value effectively. Development at the feature level therefore remains agile when features are small enough to be refined ahead of time.
The challenge about sizing a feature is that the connection between size and content isn't linear. Small parts of the feature can take a significant portion of the time to deliver.

I've faced this when developing an offer system for various types of products. Implementing the offer flow (input data to output data) takes around half the time, and configuring different products for it takes the other half. This means that delivering the first product is significantly more time-consuming than any following products.

There are a variety of ways to divide up the initial time-consuming work, and developers are the best people to recommend them. For example, the first feature could include only what is absolutely necessary by hard coding values, omitting validations, or deferring error handling until later.

3. Align the team with feature scoping and acceptance criteria

Scoping features and documenting the scope in acceptance criteria makes it easier for the entire team to understand the details of the expected delivery. The goal of this phase is to get everyone on the same page about what will be included and excluded from the feature, making it easier to decide whether to address any edge cases. The result for good acceptance criteria is a better focus on the correct details for the implementation and testing phase.

For example, in the previous offer system example, scoping would be crucial to ensure that we deliver only the parts that are needed for each product to work. Defining borders gives the developer a better understanding of where to focus on each step.

Scoping should be done collaboratively within the team, because each team member has expertise to offer about what is feasible to scope in and out. If developers haven't yet completely invested themselves in the feature, this is the step where all unknowns should be addressed.

Acceptance criteria are a method of documenting the feature scope by specifying the key requirements that must be completed before a feature is ready. These serve as a contract between team members to ensure that everyone is on the same page about the feature.

4. Split the feature into tasks that solve a single problem

Once we have a well-defined feature with strong acceptance criteria, we can divide it into smaller tasks that allow developers to work on a single problem at a time and enable parallel execution between developers.

In my experience, the more problems I try to handle at once, the more likely I am to make mistakes. Focusing on a single problem at a time improves the quality of my code. In our offer system example, a single task may be number formatter functionality. Separating this from other tasks would allow us to focus more on functionality outside of the happy path and specific use cases.

Splitting is more than just having a list of tasks to complete. Since the feature we're building is rarely identical to one we've built previously, there are also unanswered questions about how best to execute each part of it. Organizing new problems into individual tasks clarifies what needs to be done and allows us to plan for each problem.

A few years back, I had a feature that involved complicated form validation. Splitting the complex issues into separate tasks provided a specific problem to address, which I was able to work out with a small proof of concept during the refining stage. The implementation process became much more comfortable, because I already knew how things should be done and I could focus on details like how to make tests scalable.

Control leads to better code

There is a clear contrast between a good refinement process and a fast one. When tasks focus on a single problem at a time, and developers have a firm idea of how to address each problem, the implementation phase is completed in the developer's hands.

This also changes how developers are able to enjoy their work. Instead of finding their satisfaction in resolving ad-hoc challenges during implementation, when refinement is done correctly, developers feel good about being in control of the work and being able to focus on the specifics in each step. This may not create the same bursts of happiness that solving an unexpected problem does, but it does result in a more stable, positive environment during the whole development process.

Being a good developer isn't all about the code

Aki Rautio — Sun, 14 Mar 2021 21:25:04 +0000

Software development isn't just writing good code. It's also about whether the right features are being delivered at the right time.

This also means that the best developer is not the one who can write the best code. Instead, it's a combination of various abilities that allows the team to produce the right functionality at the right time.

Software development is a process

The code is newer written in isolation. It's one step in a development process delivering new features (or fixing issues). The process depends on the organization and type of project but the following three steps are always present:

A feature refinement
Development
Maintenance

The features have to be defined before any code can be written. After the feature has been developed, it needs to be delivered and maintained.
While the developer's focus is on the development step, a good developer doesn't just know how to write a good code, but he also acknowledges the other steps.In my experience, this also means that a good developer does not necessarily need to be an outstanding programmer.

The specific skills depend on the specific position, the team and the stakeholders. For example, the ability to grasp business logic and suggest alternatives allows the developer to optimize the development towards greater value within the product team. In the best case, the same benefit can be accomplished without any code, which also reduces maintenance.

Process steps

Splitting the development process into smaller parts helps to better understand what happens when the new features are being developed. The steps we use in this article are not the only way to separate the process, and they have been chosen because they help to demonstrate the useful skills.

The software development process I introduced earlier is for a single feature, but the same thing can be applied to a high level as the same cycle is repeated in each feature.

If software development is applied to a large project, we will need a technical development step to ensure that our process does not slow down due to the amount of technical debt that we have in our project.

In following four chapters I'm introducing the main areas how the good developer can bring value on high level. Each of these points will get their own in-depth articles later on.

1. Feature refinement

The aim of the feature refinement is to identify the required changes/additions to the current application and to break the feature into smaller pieces in order to be able to test and release it incrementally. Although responsibility for this process rests with a person who understands the needs of the customer, the best outcome is when the whole team is involved as soon as possible.

As a developer, I have seen two key areas to influence the result of refinements; affecting how the features are build and how long they take to develop.

Being part of the feature refinement, a good developer can influence the result of the feature to be technically more feasible and it brings the value that is defined for the feature. For example instead of developing a multistep form to request information from the user, maybe the information is available already somewhere and it can be automatically fetched.

Estimation is another important aspect of refinement, since it helps to understand how long those features will take to get to the customer. The developer has a key role to play here, as the better the prediction is made, the easier it is to set expectations for the user. Therefore a good developer should have the ability to provide a high-level estimate of how long tasks take and the ability to communicate and cope with the uncertainties of the tasks.

At the end of the estimation process, it should be reasonably clear how long the development of the feature will take and what needs to be done.

2. Development

The creation step is not just the writing of a code. It's also about having a common view about development in a team and sharing the knowledge while creating new features. This can be only done if the code and patterns are understandable to everyone and it's done with good programming practices. Therefore I'd like to raise two primary areas; high-quality discussions about development within the team and a tested and clean code.

There are plenty of ways to achieve a good conversation atmosphere inside the team and many more ways to get these conversations going at the right time. Ultimately, it comes to the willingness of individuals to interact and negotiate with each other. Having these skills is one of the most significant attributes of a good developer. Everyone does these things a little differently, but the most important part is to know your strengths and weaknesses and to find a way to improve these skills.

Based on my experience, one of the early signs of a good developer is that their code is written in a testable manner and that proper unit and integration tests are carried out as part of the creation of the feature. This does not necessarily mean that the code coverage is 100%, but to ensure that critical factors have been tested and that uses cases of the code are documented.

3. Maintenance

Maintenance in this context means all those activities that happen when the code goes to production and works as intended. While there are a lot of project related areas to take into account, every project has following two:

The first is the release process and the infrastructure. A good developer has at least an understanding of the release process since it helps to ensure that changes in the code do not break the release.

Error management is another key area. Even the best code doesn't always work as planned, so it's important to be able to recognize the cause of the problem. As a good developer, you can bring value by understanding how to set up a proper logging system and how to use it to debug problems or bottlenecks.

4. Technical development

Not every feature has direct benefits for the user. Technical debt might get too big to keep the feature development fast enough or the new features need significant changes original setup. To my experience, a good developer can both justify these changes to the team so they get prioritized accordingly and a good developer can see when those changes are needed ahead of time so they don't come as a surprise.

Reflections on developing Android application as a web developer

Aki Rautio — Sat, 09 Jan 2021 11:40:21 +0000

For a long while, I have had an idea for an android application. There is a garage in my housing complex that opens up by calling a specific mobile number. Often my mobile isn't close by when I would need to open the gate, so I thought of creating an app to solve this issue.

Starting to develop for a new platform is relatively time-consuming compared to results, so the project has been stagnating for a while. When I stumbled on the new Jetpack Compose toolkit for the UI creation, my interest got up again since the project would also give insights into where the android development is going.

Most of my software development experience comes from technologies, frameworks, and libraries used to build user interfaces for web applications so building a mobile application isn't too far from what I have used. Having specific tools and framework features to a specific platform are still something I haven't used to so here are my findings.

First setup

Compared to web development, one of the significant differences is to have a proper IDE (Android Studio). IDE tackles almost all aspects of software development from the code versioning to create, evaluate, and debug the application. It also standardizes the underlying tools and hides them very well. For instance, as long as it works, you don't have to know what kind of commands Gradle needs when building an app. Having more focus on code and the features than steps to get the application working reduces the time to get something tangible shown on a device.

With all the helpful tools IDE provides, it's really easy and simple to start doing the first project. Right now this applies to all but Jetpack Compose which is an alpha state and needs additional packages to the project. Fortunately, Google offers a pretty straightforward guide on
how to proceed, so it's not too much trouble

In total, I think it took something like 1-2 hours from downloading Android Studio to get the first application run on a device with all needed libraries (including Jetpack Compose) ready to use. In my opinion, that isn't too much considering that the same process without IDE would probably take a full day. I was also pleased with all the features provided by IDE, such as the red line indicator from errors and a wide range of automated suggestions to make code more readable.

Writing Kotlin

A new programming language, Kotlin, is a second key difference to my standard development workflow. The difference isn't too big, coming from Javascript and Typescript. Compared to Java Kotlin feels a lot more readable and easier to comprehend so development feels more satisfying.

Model View ViewModel design pattern

As part of writing an Android software, I got to write ViewModel classes which are part of the Model View ModelView design pattern. This seems to get a lot of popularity in user interface applications lately. SwiftUI on iOS is also using MVVM and VueJS and Angular both promote separation of data and view components with their implementation. MVVM doesn't too much differentiate.

A summary for this pattern is about handing UI layer and data layer separate and connecting them by ViewModel. This wasn't anything too new different from what I'm used to but having supportive elements to implement this eases up the work.

I ended up splitting the data parts even further roughly based on Josip Šalković's article. This was especially useful when using Room as a local database since database calls were handled separately from the real logic and ViewModel code ended up being a pretty high level.

Dependence injector

Dependency injection as a term is rarely used on React even though the mechanism is more or less available in there too. The idea is that dependencies can be defined as input parameters instead of defining them inside the component to give the flexibility to change the dependencies when needed. In my view, the greatest advantage is the simplicity of writing the tests, as injected dependencies are much easier to mock than closely coupled dependencies.

My choice was to use Hilt as a dependency injector because that's what the android documentation recommends. The base setup is simple and easy but Hilt does so much automatically that it's hard to comprehend what's going on behind. This isn't a big issue until something isn't working exactly as expected.

For example, I had a Repository class that didn't have dependencies so I thought of doing it as a normal class. All seemed to be good until I started to build the application and got some weird build errors. It took quite a while to figure out that the cause was missing an empty injection setup.

Although I like the simplicity that Hilt provides, it will eventually trigger bugs that take a lot of time to identify since too much magic happens behind the scenes. It would be much more work to do this manually, so I will continue to use Hilt, even with obvious downsides.

Jetpack Compose

One of the most familiar parts of the android developer surprisingly was UI development with Jetpack Compose. The idea is almost identical to React where each UI component is a function and the whole UI is composed of those smaller UI components. Android also has mutableStateIF function that handles the internal state. The IDE also has a visual preview from the components that have @Preview annotation and this feels very much like what Storybook has been.

@Composable
fun ListItem(
    title: String,
    subtitle: String
){
  val textState = remember { mutableStateOf(TextFieldValue()) }

    Column(){
        Text(text = title)
        Text(text = subtitle)
        TextField( value = textState.value, onChangeValue = { textState.value = it } )
    }
}

This certainly is another UI pattern getting more popularity. Besides Jetpack Compose, SwiftUI has a very similar type of pattern to write the UI, and more or less all web frontend frameworks are using the same pattern nowadays. I have been using this in React for quite a while and it certainly gives a huge boost to development compared to other development patterns in frontend work.

To be said Jetpack definitely isn't fully ready yet (hence the alpha state) and that certainly can be felt.

Sometimes the compiler decided to produce random errors that went away after the entire application was rebuilt. The visual preview also stopped working in the end though I think it was due to an old version of the Android Studio.
There is also some limitation on component level and on my two-month journey to finish the application, the API got a huge amount of significant changes.

Nevertheless, I can already feel how this will make UI development a lot easier in Android and it will make a transition between platforms a lot easier since there is no need to learn new patterns.

Quirks of developing to Android

Jetpack wasn't the only part where things weren't as planned:

Permissions are something that I'm not used to handling and finding the right flow took some time (+ it's still in progress)
Not all features are well defined or give an understandable error message. For example in android 10 opening activity in the background just doesn't work. No error but it just doesn't open anything.s
I tested the application with a few different android versions but testing the application with every major android version and hardware provider like Samsung would take a huge amount of time.
Android Studio is automating so many things that many tasks feel like magic. It also gives a feeling that something will break at any minute.

Adding an application to Play Store

Once I got the first version of the application ready, it was time to release it in the Google Play store and that was quite a journey. As a web developer the software tends to be released as is so once you have finished the development, it's ready to be deployed and marketing can start.

With Play Store, App needs have good descriptions, screenshots, and the marketing material beforehand and there is quite a huge amount of mandatory content to fill out even before you can submit the app package. And once everything is ready, the application will be reviewed before it's available for the customers. This will make the whole update and bug fix process a whole lot different from web development because it will take hugely longer to get the bug fixed in an application.

Findings

The most significant finding from this experience is that developing to different platforms isn't that much different anymore as it used to be. The patterns to build UI and architecture the application starts to resemble each on both web and native android even though the tools themselves may offer different features. This should make developers' life easier since knowledge from one platform can be at least somewhat utilized to other platforms.

I would also see that the patterns I used in an android application gave me a better ability to use them more on the web and especially with React that gives the freedom to experiment. For example, MVVM design pattern can be created by simply separating the data and view layer with a middle layer that ensures rerenders when data behind changes.

While there were a lot of similarities between platforms, the distribution with the mobile application is vastly different from the web. Having an application store in between the client and developer is a whole lot different experience than distributing the result straight to the user. This also brings with a bunch of new challenges to be solved like how to ensure that changes services are taken into account on multiple client versions or how to distribute bug fixes. George Orosz's blog post touches on these topics very well so I highly suggest reading his views.

While VSCode is a good text editor, I definitely will miss many more IDE level features from Android studio. One of these is the storybook-like component view next to the code. On the other hand, having used to getting strict autoformatting on save with Prettier was something I missed while writing the app.

If you are interested to see the result from this journey, the CallGates app is available on Google Play.

Decouple design from the logic with React hooks

Aki Rautio — Wed, 14 Oct 2020 17:40:20 +0000

Splitting the application logic and business logic has been long a good practice in frontend development since it eases up changing and testing each part independently. The same can be also with UX logic and design.

The idea for this writing came when I was trying to find a proper library for the date picker component in React. Most of the packages are including both application logic and design in the same package which tends to lead to a hacky solution on the project side if any customization is needed.

This can be also seen in our projects where coupling the design and the logic tightly together makes any new features to increase the component size. This tends to lead to feature-rich but huge components that are hard to test and ensure that all things work correctly.

Writing stateless components

Decoupling the logic and design starts by creating stateless components which are implementing the parts of the required design.

To make this practical, let's do a custom tab component with this logic. For the design part, we can have two components; TabItem to show a single tab and TabContainer to wrap around the tabs.


interface TabItemProps {
    onClick: (value: String) => void,
    isSelected : Boolean,
    children: String
}

const TabItem = ({
  onClick,
  isSelected,
  children,
}: TabItemProps)  => (
  <button onClick={() => onClick(children)} className={isSelected ? "selected"}>
    {children}
  </button>
)

interface TabContainerProps {
    children: React.ReactNode
}

const TabContainer = ({ children }: TabContainerProps)=> (
  <div>
    {children}
    </div>
)

When creating these stateless components, the focus should be on how to split the functionality into smaller independent containers. There are not too many rules regarding this, and a lot of different solutions work, so the most beneficial practice is to keep consistent.

Even though the components are not including any state inside, they will hold some logic based on given properties so that they can execute required the user experience. Depending on your solution, the components can either hold the logic or just the states derived from the logic.

For example, the TabItem has isSelected property that explicitly describes the use case. The same could be done by active property that is more generic and gives the logic part more power to decide when a single tab is active.

Ensuring that stateless component looks exactly as they should, we should create tests for them. Since they don't hold internal logic, testing is a lot easier since we only need to ensure that each state works as expected. This can become by either using snapshot testing (from DOM or screenshot) with either local tools like Storybooks storyshots or Chromatic.

Adding hooks into stateless components

To make those stateless components work together, we'll create a hook that handles all the required logic. It necessary doesn't need to contain the state but it should pass all the data and actions to components.


interface Tab {
  name: String,
  value: String,
  isSelected: Boolean,
  isDisabled: Boolean?
}


interface useTabHook {
    tabList: Tab[],
    onChangeTab: (value: String) => void
    content: (selectedTab: String) => any
}

const useTabs = (tabs : Tab[], content: any) : useTabHook =>  {

    const [selectedTab, setSelectedTab] = React.useState(tabs[0]?.value)

  return {
        tabList: (tabs || []).map(item => ({ ...item, isSelected: selectedTab === item?.value })),
        onChangeTab: (value) => setSelectedTab(value),
        content: content(selectedTab)
    };
}

The scope of the hooks should mainly to cover the logic and exclude all style related variables (classnames or inline styles). Sometimes it may make sense to add accessibility or utility properties for the styles coming from the hook.

The hooks should also consume all the external data and actions the component is needing even though some of the data goes straight to return values. Including all necessary properties to the hook makes the usage a lot easier since it's known where the data is coming, and there are no hidden requirements.

Since the hook handles all the data transformation and action execution, a developer-friendly API and composable internal parts are the keys to success. They may not be very visible when the component is relatively simple, like in our example, but once complexity increases, making an effort to the API results a huge difference.

Since we are only focusing on data transformation and actions, testing is more straight forward. There is no need to use DOM as an intermediate layer, but we can do all the purely to hooks input and out properties.
There is also a library to ease up testing the hook called react-hooks-testing-library.

Combine stateless components and the hook

Lastly, we need to combine the logic to the design by creating a component that uses the stateless component in a manner the hook defines.

interface TabsProps {
  tabs: Tab[];
  children: React.ReactNode;
}

const Tabs = ({ tabs, children }: TabsProps) => {
  const { tabList, onChangeTab, content } = useTabs(tabs, children)

  return (
    <React.Fragment>
      <TabContainer>
        <React.Fragment>
          {tabList.map(({ name, ...tab }) => (
            <TabItem {...tab} onClick={onChangeTab}>
              {name}
            </TabItem>
          ))}
        </React.Fragment>
      </TabContainer>
      {children}
    </React.Fragment>
  )
}

Both stateless components and the hook have been tested thoroughly so the main component only needs an integration level testing to check that both elements work properly together. In our example, the tests would ensure the Tabs component is rendered properly, and the key flows are working as expected.

Advantages and disadvantages of this practice

Decoupling makes testing a lot easier since we can use the correct tools and practices for both design and logic. While logic testing is about checking outputs after certain actions, design testing is more of checking that DOM/rendered components. These need relatively different tools and testing practices so mixing them up due to coupling not only creates more tests but also creates unnecessary work for both test types.

While testing something that can be handled with coupled components, the real advantage comes when there are new requirements for either design or logic that doesn't match with already made ones. For example, you may have multiple products that are using the same codebase and have slightly different requirements for the design or the logic.

For example, in our case, if there are products with the same type of tab logic but different design, the hook part can be reused. And if one of the tabs needs a disabled that can be extended by composing a new hook with disabled logic around the current hook.

// Additional TabItem component with disabled state
const DisabledTabItem = ({
  onClick,
    isSelected,
  isDisabled,
  children,
  value
}): {
    onClick: (MouseEvent<HTMLButtonElement>) => void,
    isSelected : Boolean,
  isDisabled: Boolean,
    children: String,
  value: String
} => (
  <button onClick={onClick} value={value} disabled={isSelected}>
    {children}
  </button>
)

// Extented hook to handle disabled state
const useDisabledTabs = (input) => {
  const content = useTabs(input)

  return {
    ...content,
    onChange: (props) => {
      const tab = input.tabs.find((item) => item.value === props.target.value && item.isDisabled)
      if (tab !== undefined) {
        content.onChange(props)
      }
    },
  }
}

// Combining extra features
const TabsWithDisable = ({ tabs, children }) => {
  const { tabList, onChangeTab, content } = useDisabledTabs({
    tabs,
    content: children,
  })

  return (
    <React.Fragment>
      <TabContainer>
        {tabList.forEach(({ text, ...tab }) => (
          <DisabledTabItem {...tab} onClick={onChangeTab}>
            {text}
          </DisabledTabItem>
        ))}
      </TabContainer>
      {content}
    </React.Fragment>
  )
}

In both the reusable parts are easy to take and only the new code needs to be tested again. This makes development a lot faster since there are no breaking changes towards already created components.

Of course, these advantages don't come for free. Decoupling the logic and design also enables one to write code on top of the existing code that increases the level of dependencies. A high dependency tree will also lead to slow development if the base dependencies eventually need breaking changes. High dependency trees increase the difficulty to see the overall picture so there should be a balance between building on top and refactoring the current code.

Examples

I have been happy to see that this practices has gotten more momentum lately and there are pretty good production ready packages to use.

Datepicker hooks

First package I have been seen using this is @datepicker-react/hooks. There is also styled-components package for design but the hooks part can be used separately.

Adobe's React Spectrum

React Spectrum takes this even further by a hook library for both accessibility and logic for the most common use cases.

If you know any more like this please write a comment! I would so much want know if there are more package like this.

Summary

Decoupling design and logic can be done with a hook and stateless components. This enables creating new components based on the already written logic or design and test both logic and design separately.

Document and test a common component library

Aki Rautio — Fri, 24 Jul 2020 05:32:49 +0000

Earlier in this series, we have gone through how to create your component library with different methods. Besides the tools to create the components themselves, documentation and testing create a lot of value to your library.

Components in React consist of three ideas; understanding each state of the components, understanding the transitions between different states, and understanding the interaction in a component.

For example, an Accordion component has two significant states, either one of the items is opened or we don't show any open items. Closing and opening the item can be animated which creates a transition between two states and interaction generally is done by clicking the header of the item.

Developing the following kind of a component can be done straight at the spot, but testing all states from the components can be a bit tricky in that specific spot especially if it connects with external data. Luckily there are a lot of isolated development tools that help to show all the states at once and even check whether there are any changes to all those states between commits. Combining these two features makes component development a lot more reliable and faster.

One of these (and probably most popular) isolated development tools is Storybook. While there are other choices available (like Styleguidist and React-Cosmos), Storybook combines both documentation in an isolated development environment and testing the changes between commit to the package which works pretty well and is relatively easy to set up.

Creating stories to cover all the states

To speed up the development, you can create all the key states in Storybook and write your components based on them. In our Accordion example we defined, two states; one opened and all closed. Writing them in the storybook would look like this.

import * as React from 'react'

import Accordion from '../src/Accordion/Accordion'

export default { title: 'Accordion' }

export const AccordionClosed = () => {
  return ['First', 'Second', 'Third'].map((item, index) => (
    <Accordion key={index} index={index} expanded={false}>
      <div>{item}</div>
    </Accordion>
  ))
}

export const AccordionSelectected = () => {
  return ['First', 'Second', 'Third'].map((item, index) => (
    <Accordion key={index} index={index} expanded={1}>
      <div>{item}</div>
    </Accordion>
  ))
}

From https://github.com/ARautio/common-components-post/tree/master/packages/document-and-test

Besides these two, we probably would like to try out the interaction to ensure that it works correctly and transitions look good. So we could also add the controlled version from the Accordion.

const AccordionControlled = () => {
  const [selected, setSelected] = React.useState(0)
  return ['First', 'Second', 'Third'].map((item, index) => (
    <Accordion
      key={index}
      index={index}
      expanded={selected}
      setExpanded={setSelected}
    >
      <div>{item}</div>
    </Accordion>
  ))
}

export const AccordionDynamic = () => {
  return <AccordionControlled />
}

From https://github.com/ARautio/common-components-post/tree/master/packages/document-and-test

This all will create pages in Storybook which one can go back forth depending on which state is under development. For example, changing the color of the selected item would be easy to check out from this particular view.

Storybook also offers better documentation and component property listing which brings the documentation even more available for everyone. In our example having the list of states and a dynamic component is enough since we are focusing on speeding the development and checking the states. If you would use this for documentation it would be good to add documentation of the properties and some text how the setup works.

Testing

Testing in Storybook can be done a couple of ways, either by generating a text or image snapshot from React components (Storyshots) with Jest and comparing it to the latest version. Both of these have their caveat points, but in general, they help to recognize unwanted changes.

When using text snapshots with Storyshots, the test generates a snapfile from the story and compares it with the previous version to see if there are any changes. If you have added all possible states to the story, only transitions and integrations need to be tested out anymore. While snapfile makes it easy to see which components are changing, they generally don't provide a too good experience to understand what has been changed.

exports[`Storyshots Accordion Accordion Down 1`] = `
Array [
  <div
    onClick={[Function]}
    style={
      Object {
        "backgroundColor": "blue",
        "cursor": "pointer",
        "margin": "2px",
        "padding": "12px",
      }
    }
  >
    <div>
      First
    </div>
  </div>,
  <div
    onClick={[Function]}
    style={
      Object {
        "backgroundColor": "blue",
        "cursor": "pointer",
        "margin": "2px",
        "padding": "12px",
      }
    }
  >
    <div>
      Second
    </div>
  </div>,
  <div
    onClick={[Function]}
    style={
      Object {
        "backgroundColor": "blue",
        "cursor": "pointer",
        "margin": "2px",
        "padding": "12px",
      }
    }
  >
    <div>
      Third
    </div>
  </div>,
]
`;

Image snapshot with storyshots-puppeteer is one level higher from text snapshots because it compares generated images instead of the code. This gives a much easier way to see those differences but it also will give more false positives. Every time the code is generated to html page, there might be some 1px changes that trigger the change so the threshold needs to be defined properly. The positive side of the false positive is that they are relatively easy to check since test produces a visual diff.

Covering all the key states of the components inside storybook and adding storyshots or storyshots-puppeteer to test those states, will ensure that you don't get surprised by changes. It also enables you to focus on testing the interactions and transitions between interactions with other methods (like Jest + react-testing-library) which saves your time.

All this doesn't come without some costs because running all the tests will take significant time. In one of my applications, the total running time for roughly 1000 tests is around 4-5 minutes. It would be advisable if possible to run these tests within CI/CD so that they won't block you from writing the code.

Another unfortunate challenge with snapshot testing is that they are done in isolation. This means that even though you had covered all the states of the component, it still may fail in your application because you didn't take into account it's surroundings. For example in one of my applications, the ID of the component overlapped with other components and showed the component differently than in Storybook.

Both image testing and filenapshot testing also fail to show any issues with a specific browser because they are only focusing on either code or chrome. For multiple browser testing, there are extended tools like Chromatic but they certain are not foolproof either.

Summary

Documenting and testing React components in isolation eases up development because you are more aware of the changes that are happening to your components and you can faster check each key state of the component. Storybook is a compelling option for documentation and testing because it enables you to create all these states fast and has a possibility for automated tests without too much hassle. If your components are changing, the tests will notify you even when you wouldn't notice. This all though doesn't come without cost. Tests take a while to run and isolated development doesn't take into account it's surroundings. Unfortunately, the design testing only happens inside chrome but understanding the biggest effect usually is enough.

If you want to check the code by yourself, the working demo is in my common components repository.

Abstractions in React and how we are building forms

Aki Rautio — Mon, 13 Jan 2020 06:29:50 +0000

Abstractions in general

Abstraction is a result of a process to generalize the context and arrange and hide the complexity of the internals. The whole computer science is based on this idea and if you are a front-end developer, there are multiple layers of abstractions already under the code you are writing. Abstraction is a very powerful concept and it speeds up development hugely if done correctly.

We see abstractions all around us and not just in software development. For example, automatic transmission in a car has two gears, R, D. These shifts abstract the necessary action to make the car either forward or backward so that the user can focus on driving. For example, if a user wants to make a car to go backward, the only two actions the user needs to think is putting the shift into R(everse) and pressing a gas pedal.

The same goes for programming where we continuously use abstraction. It begins at a very low level where the charge of the electrical current is converted into zeros and ones and goes all the way up to the ideas of the application you are developing. On a higher level, abstraction can be for example functions that standardize certain processes or classes which create structures for the data.

In React abstractions are done by using composition. Higher-level components combine standardized lower-level components to be part of the user interface together. For example, a button could be part of the feedback form which can be part of the contact page. Each of the levels hides relevant logic inside the component and exposes necessary parts outside.

For example, if we have a component that is responsible for an accordion, we can reuse the same component instead of re-writing it when we want an accordion to be part of the screen. We may need to have a different design or a bit different functionality but as long as the accordion in a screen acts as accordion, we can reuse the base functionality.

The key to success with the composition is to find the right abstraction layers for the project's components. Too many and too few layers of abstraction risk having redundant code and decelerating development speed. Too large abstraction layers mean that smaller common code components are repeated in each component. At the same time, too small abstractions repeat the usage of the components more than needed and having too many layers of code will slow the initial development.

The proper levels of abstraction are hard to estimate before the significant parts of the application are ready and incorrect abstraction levels are the usual a cause for the need of refactoring later on. Defining the responsibilities of the components before development helps to reduce the amount of needed refactoring because it forces to justify the decisions. I can also suggest to create a bit too many abstraction layers than too few because layers are easier and cheaper to combine.

In our accordion example, we first decided to expose the reveal and collapse functionality and color theme outside which means that accordion isn't any more responsible for that. This also means that we expect those two properties to differentiate a lot between the screen. Analyzing and determining the responsibilities for the components will help out see how components should be built the way that they are composable for your application. For me, this became obvious when in the latest project I have been involved.

Case: Forms in frontend of enterprise application

Around a year ago we started to build an application to speed up one of the company's processes. As usual with all these kinds of business applications, the software would handle user inputs to fill the necessary data and then turn it to a product. I'll use this project to showcase how the abstraction worked for us. I'm going to focus on how we build forms since they were the key for this software and they ended up being the best example of an abstraction that I have done.

Starting a project

Let's start with the starting point to get some understanding of the factors leading up to the decision we took. When the project began, the final state of the process was unknown like it usually is in agile development. Nonetheless, this allowed us to deal with a lot of uncertainty when defining abstracts, leading to much more careful analysis before the components were defined.

In the context of forms, the base requirements were that we could have multiple of forms with different inputs. For me, this meant that we should make the form components extendable to as many situations as we could think while keeping the core as standard as possible.

How we abstracted forms

Before we could start building the abstractions, we needed to understand the purpose of the forms. In our case, they are part of the process where a user can either create new data or alter the current data. While most of the data points are independent of each other, we still wanted to ensure that we can handle dependency either between the form fields or between a form field and a value from the server.

The purpose of the fields is also to limit the given set of values. Data types are the general cause to limit the input. For example, when requesting a number input, we should limit users' ability to give something else. We also should be able to limit the input to a certain list of values by either limiting the input or validating the input.

This process showed that we should have two abstractions; form and form field. Besides that, we noticed that we may have different types of fields if we want to limit the input in different ways.

Form

Based on the previous process description we decided that the form in our case will be responsible for handling the state of the form data and validations. It should be also possible to give initial values and trigger the submit. The form shouldn't care where initial values come from or what happens on submit which means that these two should be exposed.

const Form = ({ initialValues, onSubmit, children }) => {

  return children({ ... })
}

Field

For the fields, we defined that we would need different types of limits for what the user can inputs. If there would be just a couple of different options it would make sense to include the logic inside the abstraction. For us, it was obvious from the beginning that we would have a lot of different types of data so we should expose the logic outside. And this wouldn't be only the logic but also UI part of each limit. For example, when we want user only to choose from the list, we should create a UI (ie. a drop-down) for that.

All field elements also had some common elements like a label on the top or the side of the input and possible error or information message under the input. These we decided to include inside the abstraction since we expected these to be part of the all form fields.

The result of these two decisions ended up creating two different abstractions. A field that is responsible for the data and surroundings of the input and an input type that is responsible to show the input field. Each of the different input types like TextInput would be their components which would all fill the same responsibility but a different way.

const Field = ({ name, label, inputComponent: Input, inputProps }) => {
  const value = undefined /*  Presents the value */
  const onChange = undefined /* Changes the value */
  return (
    <React.Fragment>
      {label}
      <Input
        name={name}
        value={value}
        onChange={onChange}
        {...inputProps}
      />
    </React.Fragment>
  )
}

// Text input in here is an example
// The props would be the same for all inputTypes
const TextInput = ({ name, value, ...props}) => (...)


const App = () => (
<Form>
  <Field
    label='Test input'
    name='TestElement'
    inputComponent={TextInput}
  />
</Form>    
)

Executing the abstraction

After we got the abstractions and requirements for those abstractions ready, it was clear that our setup is universal so someone else should have solved the problem already. Using a ready-made package would ease our job because we wouldn't have to build everything from scratch. After some exploration, we ended up using Formik inside our abstraction.

I would like to note that we are not exposing Formik to our application fully but only on Form and Field level. Formik is only filling the functionality of the abstraction, not creating it for us. This gives us an option to replace the package if we ever need something different in the future and we can also extend our abstraction beyond what Formik provides. The downside of this practice is that we need to write additional integration tests to ensure that Formik works along with our components as it should.

Creating input types

The last piece from the form setup was the input types. Since on the Field level we exposed the input, we would need to have a separate component to fill the responsibility.

It became very obvious while we had created some of these input types that besides data types (ie. text, number, date), the input type component depends on how we want to limit users' selection. For example text, input and group of radio items serve the same purpose but limit the selection very differently. We ended up having roughly 20 different input types in our application. The reason for so many components was that we wanted to abstract each input separately. For example text and number, input looks almost the same but they act differently. For the developer, it would be also easier to distinguish the inputs if they are different components.

This didn't make us repeat a lot of code since the input components were composed of smaller components. I have liked very much the way atomic design splits components because it describes the abstraction layers reasonably well and helps to keep components composable.

For inputs we created two abstraction layers:

Atoms - single functionality component like the design of the input field, functionality of a tooltip popup.
Molecules - composes atoms to build higher-level items like in our case input type component.

In our case, for example, the input component was reused between half of the input components because it was so generic. Probably the best example of having composable atoms in our case is Datepicker.

Datepicker example

In the beginning, we used the browser way to handle dates but since we wanted to have the same looking field in all browsers, we decided to do our own. After exploring the available packages and we decided to use fantastic @datepicker-react/hooks hooks and create our design on top of that.

Since we already had a lot of atoms developed, we only needed to create the calendar design which took something like 1.5 days to do from start till the end including tests. In my opinion, this demonstrates the power of the well-chosen abstraction layers which help to generalize the small component into composable atoms.

Conclusions

Generic abstract and composable components speed up development as each new feature also generates reusable components. Once we started developing the Datepicker, this became obvious to us. We've already had all the other components except the calendar itself.

Defining responsibilities for the abstracted components eases up selecting the exposed and hidden logic inside the component. It makes the conversation more constructive within the team as we end up talking about architecture rather than implementation. For example, we specified at the beginning that we expose the input component outside of our Field component. The strongest reasoning for this was that we may end up with a significant amount of different types of fields and we don't want to limit usage inside the field.

Structuring the abstraction layers with some rules helps to declare the responsibilities and connection between abstraction layers. We used atomic design as a base for these rules. It defines five abstraction layers and gives them high-level responsibilities. This helps in the beginning to establish components which have the same abstraction level.

Thanks for reading this. If you have had same experience or have any comments or questions, I would gladly hear them.

Optional chaining with React

Aki Rautio — Mon, 09 Dec 2019 05:39:34 +0000

13.1.2020 UPDATE: Babel 7.8.0 supports optional chaining out of the box

Optional Chaining is one of the most requested features in Javascript (and Typescript) which is no wonder since it solves a very fundamental problem; accessing the property from a dynamic deep object safely.


// A deep structure example 
const deepObject = { 
  firstLevel: { 
    secondLevel: { 
      thirdLevel: 'value' 
    }
  }
}

// Accessing thirdLevel safely without optional chaining
const thirdLevelValue = (((deepObject || {}).firstLevel || {}).secondLevel || {}).thirdLevel

// Accessing thirdLevel safely with optional chaining
const thirdLevelValue = deepObject?.firstLevel?.secondLevel?.thirdLevel

The main advantage of using optional chaining is a smaller and cleaner code which makes it easier to comprehend once people get used to the syntax.

How to use optional chaining

Last autumn Optional Chaining proposal got to the Candidate stage (stage 3) which means that the specification is very close to the final version. This change resulted it to be part of Typescript 3.7 in late October 2019 and Create React App 3.3.0 at the beginning of December 2019. Also supporting tools like Prettier have already added the support.

If you are using one of these, then optional chaining should work out of the box. At the current state (December 2019) the major editors like VSCode may need a bit of configuration to handle the new syntax but I would expect this to be changed very soon. If you have some trouble, check Configuring VSCode to handle optional chaining-topic from below.

Using Optional chaining with Babel

Typescript or CRA is luckily not the requirement to use optional chaining when developing with React. You can do the same with Babel 7.8.0 and greater or with optional chaining plugin (@babel/plugin-proposal-optional-chaining)

Since babel usually isn't used alone but as part of the toolchain, the required packages may differ from setup to setup. If you are starting to use babel, I would suggest to first follow one of these tutorials / repos:

If you have older than 7.8.0, you need to install optional chaining plugin with following command:

npm install --save-dev @babel/plugin-proposal-optional-chaining

and adding it to .babelrc

{
  ...,
  "plugins": ["@babel/plugin-proposal-optional-chaining"]
}

After this you should have a working setup.

Configuring VSCode to handle optional chaining

As a default, VSCode uses typescript checking for Javascript React code and currently this isn't supporting optional chaining. There are ways to fix this:

Install ms-vscode.vscode-typescript-next extension which adds support for new typescript features including optional chaining to
Disabling typescript and javascript checking and installing and setting Eslint extention to VSCode and configuring eslint to handle optional chaining.

Configuring Eslint to handle new syntax

Eslint needs a babel-eslint package to understand the new syntax.

npm install --save-dev babel-eslint

It also needs addtional configuration to .eslintrc

{
  "parser": "babel-eslint",
  ...
}

Advantages to use optional chaining compared to other options

If you have been developing with Javascript (and especially with React) for some time, you may have used some functions to handle dynamic longer paths that shouldn't fail. It may have been either internally develop a solution or a function from the external package like Get from Lodash or Path from Ramda.

All these functions are still as usable as they used to be but using a future native way in code makes it more future proof and reduces the amount of external code needed. Right now the optional chaining needs to be always transpiled but that won't be the case in the future. Once browsers and NodeJS start supporting it, the transpiling can be dropped without the need to change the code.

Creating a common component library with Component library (Material UI, BaseWeb, Chakra-UI)

Aki Rautio — Tue, 03 Dec 2019 06:47:50 +0000

Starting to create a common component library with a ready-made component library bring the most value in the beginning. These component libraries usually include some set of frequently used elements on the web and also give a chance for theming to speed up developing.

There is a long history of ready-made component libraries that starts even before React. One of the most popular ones has been Bootstrap for a very long time. Due to more complex design setups and better tools, a lot of ready-made component libraries for React have popping up in past years. Many of them are developed or at least initiated by big tech companies who also use them internally.

Reasoning to use component libraries

The biggest advantage of using a ready-made component library is that a lot of components have been already developed and tested before the project even starts to develop. This gives a boost at the beginning of the project since no time spend on writing the basic components like buttons and typography elements. That time can be used for feature development instead.

Most if not all ready-made component libraries also provide theming, so that design of the components can be aligned with the project in hand.

Though there are two risks using a ready-made component library. Firstly the project will be very dependent on the library so any issues or limitations in components from library will take time to get sorted out.

The ready-made component library also dictates pretty much which kind of tools should be used for developing the design. For example, Material UI uses the CSS-in-JS through their internal styled function. Using styled-components or pure CSS will cause issues and unnecessary complexity to the project.

Available ready made component libraries

Probably one of the most known ready-made component library nowadays is Material UI which is based on Google material design. There are also tons of other options available, though many of them are still pretty young.

I would start by looking following list first:

All mentioned packages are currently in active development so new features and fixes are coming constantly. While Material UI is the most popular one, all of them provide something unique.

BaseWeb uses Styletron and makes override the base style while Elastic UI enables to use both scss and styled-component and offers a big variety of components. Reakit focuses on keeping a bundle size very small and ChakraUI has all components accessible.

How to select the one for me

Since a component library will dictate a big part of the application, it's important to make a decision that fits to the project. Each project should use their parameters to define what fits but a good start would be to ensure that tools align, compatibility is enough for project needs and there are needed a component for the project.

For the project, it would help a lot if the component library would use the same tools as the project itself (like styled-components) or that the tools the library uses, align with the idea what the project has. For example, BaseWeb uses styletron which is pretty close to styled-components but using styled-components and styletron in same project doesn't make sense.

Another risk point is compatibility. Even a well made component library may cause a lot of issues if it's not aligned with other packages in projects. The biggest risks usually depend on the project but forms are usually the ones that cause issues. If component don't pass the actions or ref through, it may limit the usage of certain packages.

Even a well build component library isn't usable if it's lacking many of the needed components in a project. Unfortunately packages group and name the components a bit differently so it takes quite some time to go through the list. It should also be taken into account that if a package has quite low-level (like popper and transition) components, there is less need to be fully fitting since those components should a lot easier to compose together from low level components.

My experience

I have been using Material UI, BaseWeb and Chakra-UI. In my opinion, all of them work very well in their scope. If I would focus on creating a web application mostly to mobile, I would probably use Material UI due to strong similarities to Android design language.

For smaller projects, I have used BaseWeb and ChakraUI due to easy extendability and CSS-in-JS support. While both felt easy to use and simple to modify to my design, I liked more ChakraUI since it used styled-components.

Summary

Component libraries have a long history from the time before React. One of the most popular ones has been Bootstrap but nowadays there are a lot options that work better in React.

These libraries usually bring a good amount of ready-made components which will ease up the development in the beginning and set a base for a common component library.

The most popular ready-made component package is Material UI but there are a lot of smaller ones that may give a better result for your specific project.

The importance is to create the criteria for your project and select the one that fits the best. The criteria can include underlying tools in package, extendability and component amount in relation to what's needed.

This is a second post from the series *Speed up development by creating a common Component library. The later posts will cover documentation of common component library.*

Creating a common component library with CSS-in-JS (Styled Components, JSS, Emotion)

Aki Rautio — Sun, 24 Nov 2019 13:56:21 +0000

CSS-in-JS is a wide term that covers a lot of different practices that enable us to write styles straight to React components. Combining style to functionality gives a lot more flexibility to write state-dependent styles and this also fixes the issue of having the only one namespace.

In a most simplistic form, this can be done by writing styles straight to HTML tags through a style property but for any bigger application, this brings some downsides. Even though the styles are written multiple times, inline styling will be kept in DOM under each component which increases the size of the DOM very fast and decreases the performance. Luckily there are many ways to solve this issue.

const Component = (props) => (
  <div style={{
    backgroundColor: 'black',
    border: '1px solid black'
    }}
  {...props}  
  >
    {children}
  </div>
)

Tools

CSS-in-JS packages focus on enhancing a developer experience by bringing better extendability and theming, and performance by compiling styles back to CSS classes. Due to a fastly increased interest in this technique, a lot of packages have been created to include styling to React components. One of the most popular actively developed packages are:

Besides these, there are a lot of different options so you are not limited to these five choices. Though I wouldn't too much look for the performance results since all of the biggest packages are usually fast enough. Most of the tools use randomly generated class names to avoid multiplying styles in DOM.

In general, these tools can be split into two categories; ones which help out creating class names easier (like JSS and Linaria) and ones that abstract the class names (like Styled Components or Emotion).

Setup

Unlike CSS and SASS, CSS-in-JS doesn't need a complicated setup because it doesn't require compiling. The minimum setup is to install the package and import it when needed.

Example with JSS

JSS does styling by generating a random class name based on given configuration and this class name which then can be used in the component. It automatically adds CSS under head tag so we don't have to worry about it.

import React from 'react'
import { createUseStyles, useTheme } from 'react-jss'

const useStyles = createUseStyles({
  myButton: {
    padding: theme.big ? 8 : 4,
    '& span': {
      fontWeight: 'bold',
      color: 'white'
    }
  }
})

const JSSButton = ({ children, big, ...props }) => {
  const classes = useStyles({ big, ...props })
  return (
    <button className={classes.myButton}>
      <span>{children}</span>
    </button>
  )
}

Example with Styled components

Styled components handle both component and styles together inside the styled function and it enables us to use template literals when creating styles, which is pretty close to normal CSS.

const StyledButton = styled(({ children, ...props }) => (
  <button {...props}>
    <span>{children}</span>
  </button>
))`
  padding: ${({ big }) => (big ? '8px' : '4px')};
  & span {
    font-weight: bold;
    color: white;
  }
`

Extending

One of the greatest features on CSS-in-JS is extendability. This makes it very easy to create common components which can be later extended to more detailed. For example if we would like to extend the StyledButton to have extra borders, it would look like this:

const BorderedStyledButton = styled(StyledButton)`
  border: 1px solid black;
`

Extendability brings the power to modify the base elements as much as needed but it also poses risk to have an inconsistent design due to many extended features. That's why it should be used only when we add extra feature like rotatability to Icon or hover effect to specific places.

Theming

Most of the CSS-in-JS packages also provide theming support. In theming we separate common variables like colors to the shared location. When the color is used in component, we refer it by the variable name instead of writing the color code.

For example in JSS and Styled Components theming works he same way as Context. First the application is wrapped with ThemeProvider and thne all theme variables are available to be used inside the theming through provider hook or props.

JSS example

import { ThemeProvider, createUseStyles, useTheme } from 'react-jss' 

const useStyles = createUseStyles(theme => ({
  myButton: {
    background: theme.colorPrimary
  }
}))


const JSSButton = ({ children, big, ...props }) => {
  const theme = useTheme() // This provides theme variables
  const classes = useStyles({ big, ...props, theme })
  return (
    <button className={classes.myButton}>
      <span>{children}</span>
    </button>
  )
}

const App () => (
<ThemeProvider theme={{ colorPrimary: 'green' }}>
  <JSSButton>
</ThemeProvider>
)

Styled components example

import styled, { ThemeProvider } from 'styled-components'


const StyledButton = styled(({ children, ...props }) => (
  <button {...props}>
    <span>{children}</span>
  </button>
))`
  background: ${({ theme }) => theme.colorPrimary}; // Theme is provided automatically
`

const App () => (
<ThemeProvider theme={{ colorPrimary: 'green' }}>
  <StyledButton>
</ThemeProvider>
)

My experience

I have been using CSS-in-JS packages for some of my projects and my personal preference has been using packages that hide the className assignment. For bigger projects, I have been relying on Styled Components with styled-system while CXS has been used in smaller ones.

In my opinion, CSS-in-JS brings value by abstracting the styling inside component which functionality and design in one place. This unifies the way I work with the components and it makes style properties (like big in a button example) to be just one parameter in a component.

Using CSS-in-JS to create a common component library makes a lot of sense since the key design can be capsulated inside the component and only needed properties can be exposed. This also helps developers who use common components to get an idea what they can change.

CSS-in-JS also makes extending components much easier and more comprehensible and this pushes to create a simple base component that can be enhanced on a need-based basis. Having a set of common extensible components makes development much faster as you never have to start from the beginning.

The downside is that this is a very developer-friendly way to handle styling so a person without knowledge of javascript may not be able to do much. This matters a lot when the project involves people with different skillsets.

Summary

The biggest advantages of CSS-in-JS are a lack of common namespace which ensures that styles will never collide and easy extendability. On the other hand, the enchancements makes the styles harder to read for the people who haven't been used to the javascript.

CSS-in-JS can be written without any packages, but the biggest value comes when it's combined with a package that handles the conversion from the style to the class name. The biggest difference between packages is whether they abstract only the class name generation or the whole component generation.

Repository css-in-js has an example how to use this in a project.

This is a third post from the series Speed up development by creating a common Component library. The later posts will cover up the other options to build the common component library and how to document the library.

Creating a common component library with CSS and SASS in React.

Aki Rautio — Wed, 30 Oct 2019 21:47:04 +0000

There are more than enough options when deciding a toolset for building the common components in React. In this post, we are going to explore how to build common components with CSS and SASS and what kind of benefits and pitfalls there are.

From the all options, CSS files with SASS addition has the lowest learning curve because these tools are used very similarly to a normal web page development. CSS files are very simple to import to React component and SASS gives some nice optional additions like variables and calculations which ease up more complex work.

Setup

Setting up a CSS and SASS files to React project also very simple to do whether you are using Create React App or Webpack.

Optional: Create a separate component library package

In case you are doing a separate package, you need to take care of both the package and the consumer sides. On a separate package, you can either distribute the CSS files as is and let the consumer do the transpiling or transpile the CSS files already on the package and distribute the result. I would suggest using the first choice since it gives more options to the consumer.

Doing transpiling on the consumer side makes package creation easy. You need to ensure that both variable and styles files are included in the package when moved to the artifactory. The files need to be just copied to the build directory and then on the consumer side referred like Javascript files:

import '@packagename/styles.css';
import '@packagename/variables.css';

If you want to do transpiling on the package side, you need to use your transpiler to create bundle style files. In case you are not using any bundler, I can suggest Rollup. Otherwise, find the needed plugin/extension. To transpile the sass files, you can use PostCss rollup plugin that includes the styles inside the javascript files or creates separate CSS bundle files.

See example from repository css-sass-rollup and sass-consumer.

Create React App

If you are using Create React App you just need to install node-sass.

npm install node-sass --save-dev

Webpack

With webpack, the project needs a bit more configuration but setup is still very straight forward. Besides node-sass we need to install sass-loader, css-loader and style-loader.

npm install node-sass sass-loader css-loader style-loader --save-dev

And then add all these to webpack.config.js

{
  test: /\.s[ac]ss$/i,
  use: ['style-loader', 'css-loader', 'sass-loader'],
}

Parcel

Parcel handles both css and scss out of the box so you can start using them immediately without any configuration.

Importing css and scss files

Importing the scss / css files inside a component happens like any other import in javascript. For example:

import React from 'react'
import './style.scss'

const Box = () => (
   <div className="box">Box</div>
 )
export default Box

Once CSS file is imported, the content becomes available everywhere in the application (as long as it is imported). This means you don't necessary have to import the css file where you are using the classes. In a sense this gives a huge flexibility regarding how to handle the styles. In a most extreme way you could import the css in a root JS file but I wouldn't suggest to do that.

How to structure the common components with css

Since CSS has a global namespace, it's very likely that at some point in a project two classnames overlap or otherwise cause issues. To mitigate these this, it's advisable to use some naming convention to separate the component from each other ensure that all unique components have their own classnames. One of the most popular is Block, Element,Modifier (BEM).

The idea with naming convention is the use same way to determine the classnames so that they are easy to recognize and reuse. Instead of making the classes be applicable for one use case like:

.disabled_btn {
 border: 1px solid $color-border;
 border-radius: $space-s;
  background-color: $color-disabled;
  color: $color-light-text;

We would split the classes to be more generic and only add the necessary additions to more specific classes.

.btn {
  border: 1px solid $color-border;
  border-radius: $space-s;
  color: $color-dark-text;
}

.btn--disabled {
  background-color: $color-disabled;
  color: $color-light-text;
}

How to use classnames properly

This structure is very extendable and easy to use in different situations. We can use the css straight away:


const CoolButton = ({ children, classNames, onClick }) => (
  <button className={classNames} onClick={onClick}>{children}<button>
)

or build a layer inside the component to handle classnames:

import classnames from 'classnames'

const Button = ({children, disabled, onClick}) => (
  <button 
    className={classnames('btn',{ 'btn--disabled': disabled })}
    onClick={onClick}
  >
   {children}
  <button>
)

Note that in the latter example we are using classnames which helps out handle multiple class names tremendously.
While both ways of using class names are correct, I would strongly recommend using the second one where class names are handled inside the common component and only properties are exposed outside.

Having properties handle the class name changes limits the amount of available different ways the component can be manipulated, which simplifies the testing and ensuring that the changes won't break the design.

Unfortunately, there is no way to extend the common component when only exposing the properties so if you need an extendable component, it could be done by creating a base component with className property and build the used component without className property.

For example if we extend the previous example the used component would look like:

const Button = ({children, disabled, onClick}) => (
  <CoolButton 
    classNames={classnames('btn',{ 'btn--disabled': disabled })}
    onClick={onClick}
  >
   {children}
  <button>
)

This way we get both extendability and limited amount of options.

Using variables from SCSS

Consistent design most often has a defined color palette and standardized spacing. With CSS and SCSS this can be done with variables added to be imported in the root javascript file (for example App.js)

The scss file could look like:


$background-Color: global #fff,
$primary1Color: global #408bbd,
$primary2Color: global #408bbd,
$secondary1Color: global none,
$secondary2Color: global #61b0e7,
...
$sSpacing: global '3px',
$mSpacing: global '6px',
$lSpacing: global '12px',
...

And to be used other scss files like:


.btn--primary {
   background-color: $primary1Color;
   padding: $sSpacing;
}

If the theme file starts to get bigger, there are also way to use SASS functions and mixins to help out keeping a better structure and easing the usages.

The benefit of using the global variables comes yet again from restrictions. When you limit yourself to use theme variables when defining colors or spacing, you also make sure that there is an easy overview what different option are used. This makes things yet again easier to test and ensure that everything works as they should.

Benefits and drawbacks of using CSS and SASS while creating the common components

As we have seen, CSS and SASS bring a powerful way to do common components/design without adding too much complexity. The component library would be easy to understand even by the developers who haven't done a lot with React and it most likely would be understandable for the people who mainly use only HTML + CSS.

The biggest advantage to use CSS and SASS is the convertibility. Since the styles are separated from the React component, the style can be reused between the frameworks. This gives a huge advantage if the same design is shared between an application that is not done only with React.

There are a couple of drawbacks too. Handling the class names manually creates a lot of possibilities to create an unmaintainable mess. The naming convention will help but this needs be managed constantly (or to have proper Eslint rules).

In my opinion, this toolset is still relevant and should be seen as an equal option when deciding what to use in a project.

Repository css-sass has an example how to use this in a project.

This is a second post from the series Speed up development by creating a common Component library. The later posts will cover up the other options to build the common component library and how to document the library.

Speed up development by creating a common component library in React

Aki Rautio — Mon, 30 Sep 2019 20:54:27 +0000

A common component library/design library is a set of visual components that builds up a base for the application. The library usually includes Typography elements like headings and paragraphs, form elements like buttons and input fields, and page elements like tabs and accordions. These can be implemented inside the project or as a separate project.

Definition

While a design library often refers only to the visual elements, a common component library can also have components that help out building screens. These may be stack or translation components, for instance. In this series, we speak about a popular library of components, but in most instances, the content also applies to design libraries.

The scope of the common component system varies depending on the needs, and although some components are included more often than others, each system is unique.

Benefits

The main driver to build a common component library is to have a consistent design language between different parts of the application (or between applications) and speed up the development. The key to a successful software project is to strike a balance between software quality and a pace of development, and both sides will benefit from a properly build component library.

With a common library, there is a possibility to create a reusable set of elements that are well tested. The time used in the beginning to develop the set takes roughly the same time as developing normal components but once they are done, the reuse starts to cut the development speed tremendously.

For example, form components can have an error handling and loading states included so that they are available for all kinds of components and work the same tested way all the time.

Options

When starting up with a common component library, there are three different ways to go:

Use SASS and css classname-helpers
Use CSS-in-JS like styled-components or emotion
Use a ready-made component library like Material-UI or base-web

The correct choice depends on a state of the project because you don't want to rewrite the current component too much. For the new project, all options are good while the existing project should select one which fits the current setup.

Using a ready-made component library like Material-UI speeds things up hugely in the beginning because there are already a huge amount of commonly used components ready and they only need styling. With two other options, the beginning will be slightly slower because most of the components need to be developed from the beginning. This may end up being beneficial later because ready-made component libraries may lack some needed features which may take more time to develop due to the way the library works.

There are many good design systems already existing and they can give inspiration for the start. Adele lists many popular ones and there are a lot more available online.

Summary

The key benefit of creating a common component library is to have a set of clearly defined and tested components that can be reused over and over again. This will speed up the development and ensure, the design stays consistent and the code is tested and working. There are a huge amount of different options for React to help out the creation of common components and the right choice depends on the state and needs of the project.

This is a first post from the series Speed up development by creating a common component library. The later posts will cover different options to build the common component library and how to document the library.

DEV Community: Aki Rautio

Different ways of writing styles in React

CSS files

CSS files / Inline CSS

SASS / LESS

CSS modules

CSS-in-JS

Styled components / Emotion

Vanilla Extract

Utility libraries like Tailwind CSS

Take control of feature implementation with a refining stage

When refinement goes wrong

Taking control of the tasks

1. Correct features create customer value

2. Reasonably sized features help with constant delivery

3. Align the team with feature scoping and acceptance criteria

4. Split the feature into tasks that solve a single problem

Control leads to better code

Being a good developer isn't all about the code

Software development is a process

Process steps

1. Feature refinement

2. Development

3. Maintenance

4. Technical development

Further reading

Reflections on developing Android application as a web developer

First setup

Writing Kotlin

Model View ViewModel design pattern

Dependence injector

Jetpack Compose

Quirks of developing to Android

Adding an application to Play Store

Findings

Decouple design from the logic with React hooks

Writing stateless components

Adding hooks into stateless components

Combine stateless components and the hook

Advantages and disadvantages of this practice

Examples

Datepicker hooks

Adobe's React Spectrum

Summary

Document and test a common component library

Creating stories to cover all the states

Testing

Summary

Abstractions in React and how we are building forms

Abstractions in general

Case: Forms in frontend of enterprise application

Starting a project

How we abstracted forms

Form

Field

Executing the abstraction

Creating input types

Datepicker example

Conclusions

Optional chaining with React

How to use optional chaining

Using Optional chaining with Babel

Configuring VSCode to handle optional chaining

Configuring Eslint to handle new syntax

Advantages to use optional chaining compared to other options

Creating a common component library with Component library (Material UI, BaseWeb, Chakra-UI)

Reasoning to use component libraries

Available ready made component libraries

How to select the one for me

My experience

Summary

Creating a common component library with CSS-in-JS (Styled Components, JSS, Emotion)

Tools

Setup

Example with JSS

Example with Styled components

Extending

Theming

JSS example

Styled components example