DEV Community: Maxim Titov

nth-child ninja power

Maxim Titov — Mon, 08 Jul 2024 16:07:05 +0000

In this article, I will share a small example of the :nth-child() pseudo-class usage that allows one to efficiently work with dynamic lists.

Problem

Let's first look at the problem I had. My task was to render a tree with different types of nodes. One of the node types presents a list, and I wanted to add alternating zebra-like backgrounds to them. Below is the visual representation of the UI I've been aiming for.

Ok, it seems that I should use a common pattern to match even nodes with an offset - 2n + 4 works for this example.

However, the difficulty is that this list of nodes is dynamic and the nodes can be different. For instance, not every node has a description, and, in this case, offset changes. If a user has permission to edit nodes, there will be an additional node after the description to select all node items for bulk editing. All of this makes offset of node items unpredictable.

According to its definition the pseudo-class :nth-child() matches elements based on the indexes of the elements in the child list of their parents. It means that the selector .nodeItem:nth-child(even) will not work as might be expected. It will highlight only .nodeItem nodes but analyse whether the element is even or not among all siblings.

Solution

:nth-child() has syntax to match selectors though. The :nth-child() argument can not only describe the function to calculate indices but also restrict them by any selector. For the node example, it looks the following way:

.nodeItem:nth-child(even of .nodeItem) {}

Now it truly scans only .nodeItem nodes and applies styles to even nodes among them!

While it is very useful major browsers have supported this syntax only since the spring of 2023 so please still be careful and consider JavaScript solutions if you need to apply a similar approach to styling your dynamic lists with support for older browsers.

5 engineering interview hints

Maxim Titov — Mon, 01 Jul 2024 06:06:23 +0000

Today, I want to share a few quick hints to help you frame your job search preparation and better understand interviewers' expectations. Recently, I participated in a podcast (in Russian) devoted to frontend interviews and preparation, where we discussed each type of interview in detail. Despite their differences, these interviews share many common elements.

I have over 10 years of engineering experience. I've interviewed candidates at various levels and been through the interview process myself. Last year, I navigated the job market and understand how challenging it is, even for senior engineers, especially if you are located outside the US or EU and looking for relocation and remote options.

So let’s go to the most interesting part.

1. Minify feedback loop

I often see engineers preparing for a job search by trying to fill every gap in their knowledge. They read computer science books, take courses, and experiment with unfamiliar frameworks and libraries. While continuous learning is great, it’s not the most effective approach for job searching. You don’t need to know everything to pass an interview. Interviews have their own rules, and it is beneficial to practice these specific skills as early as possible.

Mock interviews are invaluable for practicing and getting feedback on your answers, communication, and the actual knowledge gaps you need to address. You can ask friends, ex-colleagues, or people in your network to conduct different types of interviews for you. Another option is using online services like pramp.com, where people interview each other. Eventually, you can also take on the role of the interviewer to gain insight into what signals are expected from candidates.

I also recommend investigating the job market from day one and creating two lists. The first list should include top-priority companies where you really want to work. The second list should consist of less interesting options. Start with the second list to get a feel for the process, validate your CV, and refine your interview answers. This way, you can gather valuable information about potential questions without being too disappointed if things don't go as planned.

So try to get quick feedback on your readiness and start real interviews earlier to not be frustrated about the fact that the interviews are different from what you expected after a half year of tech preparation.

2. Focus on communication

As I mentioned earlier, interviews have their own rules. The process is not perfect, and interviewers have very limited time to assess your skills and level. This is why practicing communication is crucial. Interviewers look for signals about the tasks you've completed, the scope of your work, whether you just wrote code or organized large projects, or resolved company-level issues. It is important to focus on the value you have delivered. The helpful framework to tell about your experience is STAR - describe the project situation, task you need to complete, actions you are performed for it, and final result

For technical interviews, interviewers expect not only specific knowledge but also problem-solving skills, the ability to refine requirements, recognize task constraints, clearly deliver solutions, and test them.

You will need to articulate your experience and approach interview tasks as real problems you are solving in your usual responsibilities.

I strongly recommend speaking out loud during your tech interviews, whether it is live coding challenges, algorithmic sections, or system design interviews. Demonstrate your thought process and clearly explain your solutions. You may not always have enough time to complete the tasks, but discussing your approach helps the interviewer understand that you know how to solve it.

Remember, the interview is a dialogue, not a monologue. Always start by clarifying the requirements to ensure you understand them correctly. For coding and algorithmic tasks, explain your approach or write the algorithm in pseudocode. For system design, begin with a high-level overview before diving into details. If you go off track or encounter difficulties, the interviewer can assist you if they understand your current approach.

The best way to gauge how well you communicate your knowledge and skills is again to get feedback from mock and real interviews.

3. Prepare for specific environment

The specific challenge of interviews is that you will need to solve problems in an unfamiliar environment.

Previously, you would write solutions on paper or a whiteboard, but now most interviews are remote. The coding and algorithmic sections are usually conducted using online editors with limited syntax highlighting and code suggestions. You must be comfortable writing code in your chosen language, stay fluent, and be able to debug and test your solutions. Practice on platforms like leetcode, CodePen or CodeSandbox to solve algorithmic tasks and code challenges.

System design interviews typically require you to write down requirements, draw diagrams, and create data models. Practice on such platforms to avoid wasting valuable time figuring out how to draw your solution. I recommend Excalidraw, a minimalistic and quick-to-go tool.

4. Show your interest

Interviews usually include 5-10 minutes at the end for you to ask questions about the company. Remember, the interview is bidirectional - you're also evaluating them as your potential workplace. Research the company, understand what they do, and show your interest by asking insightful questions. For example, identify their competitors, analyze the company's unique selling points, and ask how they achieve these and what challenges they face.

Your questions can also signal your level of expertise. Ask technical questions about their engineering processes and solutions, as well as their product strategies. It's best to prepare these questions in advance.

5. Stay positive

The interview process can be tough and feel like a full-time job. It’s easy to get frustrated by questions and challenges you don't like, but staying positive is crucial. Everyone involved in hiring is trying to find the best candidate, and they have limited time to assess each one. Your best strategy is to remain positive, empathic and friendly, share well-prepared stories about your experience, and send the right signals during technical interviews.

Do not forget to rest properly and avoid burnout during this process.

Hope you find it useful! Write in comments that you would recommend others from your experience. Good luck with your upcoming interviews!

Automate your changelog and monthly product updates in your blog with AI

Maxim Titov — Tue, 23 May 2023 07:56:53 +0000

What I built

The solution helps open-source maintainers to track changes in the product and tell the users about the updates.

Category Submission: Maintainer Must-Haves

App Link

Blog with updates

Screenshots

Changelog metadata is added automatically when a new Pull Request is created.
A new version is added automatically when Pull Request is merged into the main branch.
New blog post is created based on the changelog history.
Pull request merged, blog post is on production!

Description

Maintainers have never had enough time to handle all the issues with the projects. They have to play different roles when they work on open-source projects. While it is necessary to develop and test the product itself, and solve the issues opened by the users, the maintainers have to keep history of changes and notify everyone with updates. Moreover, we have a great writer for blog posts. His name is... Sure, ChatGPT!

I created a repository that demonstrates how GitHub Actions can help the maintainers to automate all the routines related to the Changelog of the project and create nice blog posts with AI telling the users what happened to the product for the last month.

Link to Source Code

Source code

Permissive License

MIT

Background (What made you decide to build this particular app? What inspired you?)

I would appreciate having such tools some time ago when I had been working on open-source projects with a small team. It is quickly getting clear that even if your project is awesome you have to find a way to tell the world about it and provide updated information to your existing users. However, developers spent most of the time on improvements and fixes. Besides, they need to provide clear and detailed documentation, handle user feedback, and not forget to test the solution before merging a breaking API change... So the communication to the users can be lost, they just would not know what and when you changed. A Changelog file helps the team and users follow all the changes, and blog posts are able to regularly deliver useful information to a large audience so everyone will stay in touch and you don't need anymore to ping every user to try your new features.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

The demo assumes having a monorepo with the source of the main product, e.g. some awesome marketplace, a company blog with monthly product updates, and a set of GitHub actions.

The solution includes three parts:

I. When the developer creates Pull Request with a new awesome feature we want to verify that changes are added to the Changelog file. Changelog.md is located at the root of the project and contains a list of updates in the following format:

[version] [description] [date]

Besides, the newly opened PR adds metadata on the top of the Changelog using Semantic Versioning with a version level (MAJOR | MINOR | PATCH) and description. By default, it adds a new commit with a "PATCH" change so the maintainer could check and update the PR before the merge.

The workflow called add-changelog-metadata is responsible for it in the demo repository.

II. The next workflow called add-changelog-version will update changelog file after it is merged to the main branch, and transform metadata into the new version line. The previous version is increased by SemVer specification and the date of changes delivered to production is added.

III. The final workflow works by schedule and adds a new blog post written by AI. On the first day of a new month, the workflow takes the changes for the previous month, passes it to ChatGPT API, and returns his nice answer as a blog post content. The new PR would be created so the maintainer could look through it and add edits. A blog is built with Gatsby and hosted with Vercel here so right after the merge changes could be delivered to the website!

I've been very excited during this small project to play with these tools, deep dive into GitHub Actions API to find solutions for building these workflows and, of course, feel the power of the content created by AI.

Additional Resources/Info

Semantic Versioning
ChatGPT completion API
Gatsby Starter Blog
Vercel

Chart library design

Maxim Titov — Mon, 24 Apr 2023 05:41:34 +0000

Data visualization is a common task in modern software. Users can better understand large data sets visually represented and get meaningful insights. There are a bunch of libraries that help to solve it. They render different types of charts based on data that is passed into them. Usually, chart libraries use D3.js under the hood. It’s a library in charge of drawing particular chart primitives. D3.js can render data using SVG and Canvas, and later I will discuss the difference between these two approaches.

In this article, I am describing a solution for the problem of rendering different types of charts, and I will also rely on low-level rendering provided by D3.js. It might be useful not only if you need to build it but also as an exercise for preparing for a front-end engineer interview.

Requirements

First, let’s define what exactly we want to build. We want to create such a component that will render a chart of a certain type based on any data set. We also want to customize how it looks, and we want to interact with the data. It means the component should do the following:

Take data and render charts of different types (e.g. bar, line, pie, dot plots).
Provide styling for different groups of data, e.g. different bars could be of different colors.
Change the data scale by zooming in and out. The default min/max and step values should be calculated based on the data set or provided by a chart user.
Show a popup with the details about the section of the chart on which it is clicked (x and y values).
Render title and legend.

We also can mention some non-functional requirements:

Scalable, i.e. adding new types of charts and interactions should extend provided API without implementation modification. It responds to the open-closed principle (OCP).
Be performant, i.e. renders and interactions are fast.
Be responsive and rendered fine on various devices.
Be accessible.

There could be other features and customizations, however, we will focus on providing these since they look the most crucial and the final design is considered to be extendable.

Models

Now we know what we want to build, let’s move to the tech details. We will map some of the mentioned entities into models that we will use in our code. I use Typescript syntax to describe it but you can think about it as pseudocode.

There are some basic models below.

type ChartModel = {
  title?: string;
  xScaleDomain?: ScaleDomain;
  yScaleDomain?: ScaleDomain;
  showX?: boolean;
  showY?: boolean;
  showPopup?: boolean;
}

type ChartType = 'bar' | 'line' | 'dot';

type ChartSeriesModel<TData> = {
  data: TData;
  type: ChartType;
  xAxis: string | (data: TData) => Array<number | string>;
  yAxis: string | (data: TData) => Array<number | string>;
  style?: StyleFn;
}

type LegendModel = {
  [key: string]: string;
}

type ScaleDomain = {
  min?: number;
  max?: number;
  step?: number;
}

We have two basic models. One is for the entire chart and another is for the series that we want to draw there. All fields in ChartModel are optional, their purpose is to configure the features of the chart and customize the UI.

The required fields type, data, xAxis, and yAxis in ChartSeriesModel are necessary to understand what the user wants to render. The most interesting is what can be passed as data. There could be two approaches:

Force the user to prepare data of a certain format that our component will be working on. E.g., we can receive an array of objects, and if we know properties for the x and y axes we can group data by them and render these points (values).
Receive any data and accessor functions that will return sets of values for the x and y axes.

Depending on a specific task it makes sense to choose one of the approaches to follow simpler implementation but I want to make this design as universal as possible so the model includes generic TData which could be anything and use xAxis and yAxis methods to process the data.

We will need a couple more models for styling charts based on the data point, so we consider x and y coordinates and return a style object that contains only color for now but can be extended with more (e.g. thickness, label color and position, etc.).

type Point = {
  x: number;
  y: number;
}

type StyleObj = {
  color: string;
}

type StyleFn = (value: Point) => StyleObj;

Design

Now we have our data models ready, let’s look at the component tree we are going to create for our chart library.

The root component Chart is a wrapper for all other necessary parts: two axes components, legend, and set of series. Based on input it will choose what to render. The required part is ChartSeries. This component will choose the D3.js function based on type, pass the data and style function into it and render returned element.

Basically, we have two layers here. The first one is a component layer whose purpose is to provide interactivity and re-render DOM elements on change of the data or settings. Also, it will listen to DOM events to render popups on click and update zooming on the scroll.

The second layer is the drawing layer using D3.js. Functions written with D3.js will return elements for any particular ChartSeriesModel.type as well as for axes. D3.js allows drawing an axis by setting min/max values for data, and min/max values in pixels. It matches passed values, calculates equal ticks, and draws them with the axis line. In this design, ChartSeries is responsible for ingesting data and providing D3.js functions with scaling values. These settings can be manually defined if the chart component user sets their own min, max, and step with ChartModel.scaleDomain object.

This design allows extending library functionality as much as we need. For instance, we want to add a crosshair that shows lines parallel to axes and coordinates under the cursor. It requires adding a new component within the chart, receiving its configuration, and rendering. New D3.js functions should be provided for adding a new type of chart.

Note: the interaction layer can be implemented with vanilla JS or any framework. Depending on the specific implementation the UI could be composable according to this framework's best practices. For example, React JSX showing bar chart with x axis and legend could look like this:

<Chart model={chartModel}>
 <ChartSeries model={chartSeriesModel} />
 <ChartAxis position="bottom" />
 <Legend model={legendModel} />
</Chart>

API

The API of components can be described after we defined them and the models earlier. The Chart component should take the ChartModel as input. From these configuration data, it gets the state with zoom and scale settings.

function Chart(input: {
  model: ChartModel;
}): HTMLElement

type ChartState = {
  zoom: number;  // default value is 1
  onZoomChange: () => void;
  xScale: d3.Scale;
  yScale: d3.Scale;
}

The zoom setting will be used to tune the scale by user interaction with a chart, e.g. handling a scroll event. xScale and yScale could be either built from scale domain values defined by the user in ChartModel or calculated automatically based on the data provided for ChartSeries components. They are D3.js scales that can be of different types for different charts. Their main purpose is to map domain values to pixels on the screen.

ChartSeries should take the following:

function ChartSeries<TData>({
  model: ChartSeriesModel<TData>;
  xScale: d3.Scale;
  yScale: d3.Scale;
}): HTMLElement

type ChartSeriesState = {
  datum: Array<Point>;
}

The model describes the raw data and functions to access values for the x and y. ChartSeries should calculate an array of points and pass it into D3.js function that will draw a particular chart of a passed model.type. The datum term is used to describe input for chart function. We also should pass xScale and yScale to map values into their positions on the chart.

ChartAxis is similar for both axes which will be differentiated by the position value.

function ChartAxis({
  position: 'top' | 'right' | 'bottom' | 'left';
  scale: d3.Scale;
}): SVGElement | HTMLCanvasElement

It also has scale to properly draw an axis and place ticks with domain values on it. It also should react to scale changes. The position just sets where we want to see the axis relative to the chart.

function Legend({
  config: LegendModel;
  render?: () => HTMLElement
}): HTMLElement

Legend could render either a default view to explain different charts with their coloring (default or based on the style function provided for the ChartSeries) or a custom view provided with a render property.

Evaluation

Well, let’s check that all functional requirements are done at this moment. We provided an opportunity to render different types of charts with a custom look by providing style callback and to react to user interactions such as zooming in/out and clicking to show popups. It is also able to render a title and a legend.

The component tree structure allows combining different blocks and extending the functionality by adding new ones. New types of charts can be added by implementing new D3.js functions and including them in ChartFnFactory.

A good performance can be achieved by smart strategies rendering the data. Basically, usage of one of the frameworks will be beneficial since they care about it from the box and tries to minimize updates on the page. To help with that we could memoize calculated datum, trigger axes updates only when scaling is changed, and avoid re-rendering of static parts while data is the same (e.g. legend).

Optimizations

There are a few more optimizations we have to discuss to achieve better performance, responsiveness, and accessibility.

Since users could render popups over Chart these elements should have absolute positioning. Using translate CSS function to move them horizontally and vertically will be better from a performance perspective.

We would need height and width values in a few places to properly render axes and charts. E.g. bar height could be set up with D3.js in the following way .attr("height", function(d) { return height - yScale(d.value); }); where height is related to the chart. So the height and weight should be obtained from the parent element where it is placed and should listen to its change to be responsive.

The next range of optimizations is about accessibility. We actually already have a title and legend that describes our chart. It would be probably a nice idea to make a title to be required and additionally have showTitle: boolean = true. So even If a user switches it off we could add aria-label for screen readers. Likewise, we want to add aria-label for the legend element to make it clear.

We should verify that the colors that we use to draw charts by default contrast with the background.

Additionally, we could take care of describing axes and values better. Axes should have labels and values for ticks on them. Also, the data on the chart itself could be labeled to describe it for screen readers and better visual perception.

SVG vs Canvas

As was mentioned in the beginning D3.js library gives us a choice of how to render the data. Let’s consider the difference between SVG and Canvas, and their pros and cons.

SVG (scalable vector graphics) is an XML-based format that is similar to HTML and will be a part of a DOM tree with many shapes as children. The browser can access these shapes, bind event listeners, and manipulate and update them as with any other DOM node.

Canvas gives API to imperatively create paintings which results in a single element being added to the HTML document.

Due to this core difference, the interaction with SVG is much simpler, e.g. click event can be bonded to a node and get it immediately while canvas provides us only with coordinates (x, y) on its surface. Mapping coordinates to drawn elements require additional code. One of the strategies is to put an invisible canvas behind the real where all elements are colored differently so that they can be mapped to the datum array.

The downside of having many nodes in the DOM is that it requires more effort to render and update them in the browser. Here the usage of Canvas can be beneficial because it could quickly redraw the entire scene.

SVG will provide better responsiveness, its nodes could change their dimensions as well as other DOM nodes depending on provided styling. Canvas again requires complete redrawing.

Data binding is specific to D3.js library. Using SVG users map their data to shapes, so they are bound and can be automatically updated afterward. The data and their rendering are tightly coupled. It is different for Canvas which gives an opportunity to draw either by a set of imperative commands or create a set of dummy elements and bind them to data. While data binding makes it possible to select, enter and exit dummy elements like it is done with SVG API rendering is detached from this cycle. So the library user has to additionally care about how and when to redraw elements of a canvas scene.

To sum up, SVG is simpler to achieve interactivity and responsiveness requirements and has the benefits of data binding in D3.js. Canvas can be more performant in case of having a lot of nodes in one chart. For this design I would choose SVG, and consider Canvas for only specific cases that require rendering many nodes, e.g. let’s stick with 100 nodes threshold for it.

Conclusion

In this article, we discussed how the extendable chart library could be built. Also, we discussed the advantages and disadvantages of visualization with SVG and Canvas. I hope you will find it useful for you and I would be glad to hear your comments and ideas on how this solution could be improved.

System design behind a messenger app

Maxim Titov — Thu, 06 Apr 2023 09:21:53 +0000

We daily use messenger applications such as Whatsapp and Telegram to chat with our friends. They all have a few design solutions behind the scene that directly affect user experience. In this article, I am describing some features visible from a user perspective and explaining tech details under the hood. However, it is not a complete system design and there are a lot of topics where you could dive much deeper.

Message delivery statuses

All messengers indicate a state of a message. The application provides a user with information on whether the message was sent, delivered, and read by a recipient. This is very good seen on Whatsapp.

It shows a few stages the message goes through:

When a user just clicked a Send button the message is sent from a client device to web servers (clock icon).
When the message came to a server it sends a notification back to the client. At that moment icon changed to a single check.
The web server looks for a connection that is established between it and a recipient and sends a message. The recipient client device sends back a notification to a server and after that, the server can send a notification to the sender that the message was delivered and the icon changed to double-check.
Eventually, the recipient opens an application and reads the message. His device sends one more notification to the server and the server communicates to the sender that the message was read. The icon changed to blue-colored double-check.

The scheme below illustrates this process and brings a few more necessary design blocks to the further discussion.

The messenger app has to handle more than 100 billion messages daily or roughly a million per second. The messenger app follows the distributed design to take such a load and the important part of it is Load Balancer (LB). Load Balancer applies a particular strategy to equally distribute effort between different servers.

Messenger aims to quickly deliver messages between users and servers. Web sockets are used to ensure it. Web socket is a protocol providing duplex communication over a TCP connection. Keeping a web socket connection is cost cheaper than an HTTP connection. The client and server subscribe to each other and wait for new messages. That’s why all arrows on the scheme are bi-directional.

Different users might be connected to different web servers so we need to have Web Socket Manager. This service is responsible for providing information about connections and routing messages to a proper web server.

If the recipient is offline the message should be stored. The database should be optimized for frequent write and delete operations. Delete operation performed after the client is online and all messages are delivered to him. NoSQL database will be a choice for this case, e.g. some messengers use HBase and Cassandra to solve the task.

Background data fetching and strong consistency

The web socket protocol allows messenger apps to keep connections alive for a long time and load messages even if a user is not active right now. Mobile apps often stay in the background and are able to load new messages if your device is connected to the network. You could notice that you usually see messages immediately after you unblocked the phone and opened the app. Let's look at the desktop client that was closed for a long time and there are no background processes.

In this recording, the application opens a web socket connection only after its launch. When the connection is established new messages are received from the server. It is loaded not in one batch but one by one. It follows us to another important requirement of messenger system design. It is consistency. The sequence of messages is critical. It would be strange if a recipient gets messages in order different from the original, also messages can’t be lost. The consistency of this application is to provide messages in a strict order. There is a CAP theorem saying that any distributed data store can provide only two of the following three characteristics: Consistency, Availability, and Partition Tolerance. The applications must provide Partition tolerance, hence they have to choose between Consistency and Availability. Messenger services choose Consistency over Availability. That’s why we see the picture in the figure above when the user has to wait a few seconds for chats to be loaded.

Downloaded files caching

We discussed a few aspects of chatting, however, messengers also allow users to share media files. The last bit is about optimizing network bandwidth. Files are obviously larger than messages and it would be a nice idea to minimize the times when a user has to upload and download them. When the user uploads a file the server stores it and calculates a checksum that is unique for any particular file. If a user uploads a file that is already stored on the server, the application will look at the checksum and prevent duplication. From the user's perspective, we can try to repeat the following steps:

Upload the file. I use Telegram Saved messages to check it.
Remove it and clear the device cache.
Upload the file again.

There will be a noticeable difference between the first and second upload attempts, the second one is almost immediate.

Note: the speed of checking for duplication could depend on the user’s geolocation. Distributed systems have a lot of servers around the world so the time of response (when we talk about distributed system design we usually use the term latency) can be actually higher. If a user uploads the duplicate from a location that is different from the origin it might take more time because the closest server doesn’t have information about it.

Another thing to mention is Content Delivery Network (CDN). CDNs are used to store static content such as images and videos. They are based on the network infrastructure and allow to put the files closer to users geographically. Hence, the content is delivered faster and latency is lower.

Conclusion

We talked about a few features of messenger applications that you see daily when you are chatting with your friends, and now you can have a better understanding of system blocks and design decisions that provide us with such user experience.

Thank you for taking the time to read this article. I would love to see your feedback and favorite app features which internals you would like to know in the comments!

What’s wrong with HTML number input

Maxim Titov — Fri, 31 Mar 2023 06:39:03 +0000

The software development job is a daily problem-solving process. Developers love picking up sophisticated issues from the backlog and avoiding trivial ones. However, any task can turn into an adventure with a ton of surprises and elements of a detective job when the developer is investigating a problem and discovering reasons for unexpected behavior.

In this article, I am sharing my personal experience in creating a configurable input to type numbers, facing pitfalls along the way, and eventually, I will suggest a solution for this problem.

Requirements

Let’s look at what actually had to be done. The task is to add number input. The context is that this input is a part of the application builder so users are creating their apps from a predefined set of components. The input has the following requirements:

The component should be configurable. Particularly it has three essential properties:
- defaultValue: number - should be applied when the input is empty and not touched.
- allowDecimals: boolean - should allow typing a decimal value, increasing and decreasing by arrows should add and subtract 1 accordingly and keep the decimal part. If the prop is switched from true to false decimal value should be floored.
- allowNegative: boolean - should allow typing negative values. If the prop is false, the minimum possible value is 0. If the prop is switched from true to false negative value should be changed to 0.
The value can be changed with the help of arrow buttons, arrow keys, or manually typed.
Depending on chosen settings the input should not allow typing invalid numbers. In other words, allowed symbols are digits (0..9), optionally separators (,.) and a sign (-).
The UI should be customized including arrow buttons.

Restrictions by the specification

The first idea is to use a usual HTML input with a type number. It already has min, max and step properties that look exactly like what we need to customize behavior according to requirements. However, the HTML5 specification and browser implementations have a few peculiarities:

Setting a minimum value restricts values that a user can choose using up and down arrows but it is still necessary to handle and validate manual user input. The same for typing decimal numbers.
Decimal separator
- Chrome works with both “,” and “.”
- Firefox and Safari require “.” as a separator, the value with a comma is considered to be invalid.
While English-speaking countries use a decimal point as a preferred separator between integer and fractional parts many countries use a comma as a separator as well. Most of the standards (System of Units, versions of ISO 8601 before 2019, ISO 80000-1) stipulate that both a point and a comma can be used equally. From this perspective, Chrome's behavior looks preferable and should be consistent among different browsers.
On type validation
- Chrome filters prohibited values such as letters and punctuation marks (except decimal separators).
- Firefox and Safari allow typing any symbols. Instead, they mark the input as invalid and the value is an empty string.
Again, the support of Chrome’s behavior looks preferable because it helps a user, doesn't provide opportunities for invalid input, and eliminates the necessity of additional validation messages.
By default increment/decrement of decimals works in a different way than what was expected. It always tries to round a number and ignores a fractional part. Let’s say we have 1.5, then adding one will result in 2, not 2.5. The step can have a value equal “any” that makes increment/decrement behavior as was expected. However, it doesn’t work in the current versions of Firefox.

All the things above are actually reasonable, Chrome’s input looks almost perfect so far. Despite Firefox and Safari providing worse UX they have lower usage, and these shortages could be ignored for the first version.

The worst thing is when the customization of up and down arrows comes. For this purpose input component was added along with a custom controls component.



export const NativeNumericInput = ({ value, onValueChange }) => {
  const { min, allowDecimals } = useConfigContext();
  const [displayValue, setDisplayValue] = useState('');
  const inputRef = useRef();

  const max = Number.MAX_SAFE_INTEGER;
  const canIncrement = value < max;
  const handleIncrement = () => {
    inputRef.current.stepUp();
    const newValue = inputRef.current.value;
    onChange(Number(newValue));
  };

  const canDecrement = value > min;
  const handleDecrement = () => {
    inputRef.current.stepDown();
    const newValue = inputRef.current.value;
    onChange(Number(newValue));
  };

  const handleValueChange = (e) => {
    const newValue = e.target.value;
    setDisplayValue(newValue);

    if (newValue === '') {
      onValueChange(null);
      return;
    }

    onValueChange(Number(newValue));
  };

  return (
    <div className="native-input-container">
      <label htmlFor="native-input">Native Input</label>
      <br />
      <input
        ref={inputRef}
        type="number"
        id="native-input"
        min={min}
        step={allowDecimals ? 'any' : 1}
        value={displayValue}
        className="input-with-custom-controls"
        onChange={handleValueChange}
      />
      <NumericInputControls
        canIncrement={canIncrement}
        canDecrement={canDecrement}
        onIncrement={handleIncrement}
        onDecrement={handleDecrement}
      />
    </div>
  );
};

const NumericInputControls = ({ canIncrement, canDecrement, onIncrement, onDecrement }) => {
  return (
    <div className="numeric-input-controls">
      <button onClick={onIncrement} disabled={!canIncrement}>
        ^
      </button>
      <button onClick={onDecrement} disabled={!canDecrement}>
        ^
      </button>
    </div>
  );
};

The input component receives value as a prop, min property from the configuration which is 0 if allowNegative: false and set max to define when the buttons should be disabled. NumericInputControls is just a presentation component. The increment and decrement handlers use stepUp and stepDown methods respectively. It works fine for integers and doesn’t work for decimals. The reason is that value of the step attribute is any, and these methods throw an error INVALID_STATE_ERR. It is happening because their internal behavior multiplies the step value by n, where n is an argument of the function whose default value is 1.

This leads us to write our own implementation of increment and decrement functions. Also, it means that buttons will work the same way in all browsers including Firefox. But the keyboard events for ArrowDown and ArrowUp are still based on the native implementation of number input. Considering the fact that the benefits of specific input are not used anymore, it appears that rewriting the component with a standard text input is not much harder but allows to implement of consistent behavior for all necessary features: on type validation, decimal separators, increment and decrement for decimals.

Solution based on text input

Let’s first check how increment and decrement functions changed.



const handleIncrement = () => {
  const newValue = preciseMathSum(value ?? defaultValue ?? 0, 1);
  handleControlsValueChange(Math.min(max, newValue));
};

const handleDecrement = () => {
  const newValue = preciseMathSubtract(value ?? defaultValue ?? 0, 1);
  handleControlsValueChange(Math.max(min, newValue));
};

const handleControlsValueChange = (value) => {
  setDisplayValue(value.toString());
  onValueChange(value);
};

There are methods preciseMathSum and preciseMathSubtract to solve a floating number precision issue so fraction part length will be kept and expected. Also, the usage of Math.min and Math.max helps to avoid exiting the range of allowed values. The minimum value depends on allowNegative setting so it is either 0 or Number.MIN_SAFE_INTEGER. The maximum allows operating with numbers no more than Number.MAX_SAFE_INTEGER accordingly.

The next step is to return the keyboard support that we lost by switching off the number input behavior.



useEffect(() => {
  const handleKeydown = (e) => {
    if (e.code === 'ArrowDown' && canDecrement) {
      handleDecrement();
      e.preventDefault();
    } else if (e.code === 'ArrowUp' && canIncrement) {
      handleIncrement();
      e.preventDefault();
    }
  };

  inputRef.current.addEventListener('keydown', handleKeydown);

  return () => inputRef.current.removeEventListener('keydown', handleKeydown);
}, [canIncrement, canDecrement]);

It checks for the possibility to change the input and does the same increment and decrement operations on the keydown event only for two arrows.

The last step is to verify that the user is not allowed to put invalid values into an input. These restrictions are different depending on the component settings. The user is able to type “-”, “,” and “.” only if negative and decimal numbers are allowed.



const handleValueChange = (e) => {
  const newValue = e.target.value;
  if (!isValidNumberInput(newValue, { allowDecimals, allowNegative })) {
    return;
  }
  setDisplayValue(newValue);
  if (newValue === '') {
    onValueChange(null);
    return;
  }
  const newValueWithDecimalPoint = newValue.replace(',', '.');
  const newNumericValue = Number(newValueWithDecimalPoint);
  if (newValueWithDecimalPoint !== '' && !Number.isNaN(newNumericValue)) {
    onValueChange(newNumericValue);
  }
};

All the logic is encapsulated in isValidNumberInput utility function. It checks an input to be either a valid number or unfinished input which could become a valid number. Internally it uses pattern matching and checking edge cases, also considering allowDecimals and allowNegative values. It would be more clear with examples.



isValidNumberInput('-1', { allowDecimals: false, allowNegative: false });  // returns false
isValidNumberInput('-1', { allowDecimals: false, allowNegative: true });  // returns true
isValidNumberInput('-', { allowDecimals: false, allowNegative: true });  // returns true
isValidNumberInput('--', { allowDecimals: false, allowNegative: true });  // returns false
isValidNumberInput('1.5', { allowDecimals: false, allowNegative: false });  // returns false
isValidNumberInput('1.5', { allowDecimals: true, allowNegative: false });  // returns true
isValidNumberInput('1,5', { allowDecimals: true, allowNegative: false });  // returns true
isValidNumberInput('1.5.', { allowDecimals: true, allowNegative: false });  // returns false

After this verification, the input will be converted to a number and committed if possible. If it is not a number yet it is only set as a display value for controlled input, the actual value is kept the same.

Note: alternatively it is possible to build one regex to check the input for necessary conditions and even add it as a pattern prop to the input. However, I personally prefer to have simpler regex and additional conditions that could be more readable. Also, putting this logic in the method allows us to cover it with unit tests.

Conclusion

There is a repository with the demonstration code that is also published with Vercel if you want to play around with this case.

Despite the fact that I had to implement this task twice it was a nice exercise and interesting diving into the HTML5 specification. I hope you also enjoyed this small journey and found something useful for you!