Forem: Domantas Jurkus

React component groups under one namespace

Domantas Jurkus — Mon, 16 Mar 2026 10:34:41 +0000

A nice way of exposing a set of related React (sub)components under one namespace:

export const Header = Object.assign(
  (props: PropsWithChildren) => {
    return (
      <div className="flex">
        {props.children}
      </div>
    );
  },
  {
    IconTitle: HeaderIconTitle,
    SectionItem: HeaderSectionsItem,
    Section: HeaderSections,
  }
);

With Header defined like this, the Header and it's sub components can be used like this:

export const MainPage = () => {
  return (
    <Header>
      <Header.IconTitle
        icon={<IconPretty />}
      />
      <Header.Section>
        <Header.SectionItem
          label="foo"
          value="foo"
        />
        <Header.SectionItem
          label="bar"
          value="bar"
        />
        <Header.SectionItem
          label="baz"
          value="baz"
        />
      </Header.Section>
    </Header>
  );
};

React: avoid hooks that set default values, use getters with defaults

Domantas Jurkus — Fri, 13 Mar 2026 10:49:58 +0000

The context

A colleague of mine helped identify a pattern that has helped avoid using hooks for setting default values.

If you ever found yourself needing to write useSetDefaultSomething(), this article is for you.

The goal

When a customer opens mysite.com/?myParam=foo, I want to load the correct FooComponent. However, if mysite.com is opened with no param is set, I want it to default to FooComponent as well.

In the following component, a hook is used to set some sort of default parameter:

export const MyMainComponent = () => {
  useSetDefaultParameters();

  const { params } = useMyContext();

  return (
    <div className="...">
      {params.myParam === "foo" && <FooComponent />}
      {params.myParam === "bar" && <BarComponent />}
    ....

The hook itself monitors the url params for changes and updates a context whenever myParam changes.

export const useSetDefaultParameters = () => {
  const { myParam } = useGetQueryParam();
  const { setParam } = useMyContext();

  useEffect(() => {
    setParam("myParam", defaults["myParam"]);
  }, [myParam]);
};

The problems

UI flicker: since useEffect runs after every render, the UI will initially paint a state where urlParam is undefined before it receives the default value.
useSetDefaultParameters is a brittle side-effect: as the app gets built out, there may be different reasons for why we want urlParam to change without affecting the original MyMainComponent.

The solution

Instead of writing your app in a way that requires side-effects, a better option is:

Put what you need into a hook, eg useGetMyParam.
Make the hook return a default value if urlParam is undefined.

export const useGetMyParam = () => {
  const { myParam } = useGetQueryParam();

  return myParam || defaults["myParam"]
}

Then, our main component can be updated to:

export const MyMainComponent = () => {

  const { myParam } = useGetMyParam();

  return (
    <div className="...">
      {myParam === "foo" && <FooComponent />}
      {myParam === "bar" && <BarComponent />}
    ....

With this, we get rid of the useEffect and our UI renders the correct component from the first time 👌

Node.js gRPC calls and Promises

Domantas Jurkus — Thu, 04 Sep 2025 10:25:42 +0000

I was connecting a gRPC service with my node service and ran into an issue that i wanted to document for future sake.

The problem

I have a controller that looks like this:

export class MyController {
  static getItem = async (_req: Request, res: Response): Promise<void> => {
    const data = await myService.getItem();

    console.log('controller: ', data);

    res.status(200).json(data);
  };
}

My service looks like this:

export class IstService {
  // ... setup stuff

  getItem = async () => {
    await this.grpcClient.GetItem(
      { item_id: 'item-1234' },
      (err: any, response: Record<string, unknown>) => {
        if (err) {
          console.error(err);
          return;
        }
        console.log('service:', JSON.stringify(response));

        return response;
      }
    );
  };
}

When I call the controller, the log order is:

apps/server start:dev: [1] controller: undefined
apps/server start:dev: [1] service: {"id": "item-1234", "foo": "bar"}

Uh oh, that's not what I want. While I have an await before myService.getItem(), the controller still finishes execution first before the gRPC call finishes.

The solution

The solution to this problem is to wrap the service gRPC call into a new Promise:

export class IstService {
  // ... setup stuff

  getItem = async () => {
    return new Promise((resolve, reject) => {
      this.grpcClient.GetItem(
        { item_id: 'item-1234' },
        (err: any, response: Record<string, unknown>) => {
          if (err) {
            reject(err);
            return;
          }
          console.log('service:', JSON.stringify(response));

          resolve(response);
        }
      );
    });
  };
}

The main issue here is that this.grpcClient.GetItem does not use the async/await API - it uses the traditional callback pattern, where you essentially have to nest your code into the callback function.

JavaScript/TypeScript does not stop you from putting await on places where it does not make sense (would be nice is TypeScript had some automatic warning for pointless cases like these):

await console.log("just weird")

Slow nvm start solution: fnm

Domantas Jurkus — Wed, 27 Aug 2025 11:24:11 +0000

nvm has been causing me slow shell starts for years (2-3 second delay on each new iterm2 tab).

Switching to fnm fixes the delay and I can open tabs instantly again.

🚀

Git setup for different accounts pointing to different repos

Domantas Jurkus — Fri, 22 Aug 2025 07:42:47 +0000

I recently had an issue that looked like this:

I have a personal project on github.com in which I author commits with my personal GitHub account.
I have a company project on github.com in which I author with my company account.

I had two separate SSH keys for this, one personal and one company, however, since both projects lived in github.com, doing git pull or git push would not know which SSH key to use.

The solution (for macOS): a ~/.ssh/config file where a new DNS name is created to separate the work vs personal case:

Host github.com-company
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_algorithm_company

Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_algorithm_personal

No that i create two aliases here, github.com-company and github.com-personal.

Then, set the correct remote url for each project.

For the company project:

git remote set-url origin git@github.com-company:CompanyName/company-project

And for the personal project:

git remote set-url origin git@github.com-personal:domantasjurkus/personal-project

🚀

Accessibility Tips for Frontend Engineers

Domantas Jurkus — Thu, 31 Aug 2023 07:48:38 +0000

Note: if you are using Firefox on macOS, in order to work with the examples in this page, you need to go to System Preferences -> Keyboard -> Shortcuts and tick Use keyboard navigation to move focus between controls. MacOS does not make this obvious for some reason.

Quick tips on boosting accessibility of your web page
In this blog post, I want to share my learnings after working on an accessible UI component library for over a year. Our team was fortunate to include an accessibility expert who helped set a high bar for accessibility.

The goal of any frontend website or application should be to make it usable by as broad of an audience as possible, including people with disabilities.

In an article by the World Health Organization, in 2021 over 1 billion people lived with some form of disability.

A total of $13 trillion is estimated to be controlled by people who have those with disabilities either in their family or in their circle of friends:
https://www.rod-group.com/sites/default/files/2020%20Annual%20Report%20-%20The%20Global%20Economics%20of%20Disability.pdf

The number of federal lawsuits for inaccessible websites has also steadily increased:
https://www.adatitleiii.com/2021/04/federal-website-accessibility-lawsuits-increased-in-2020-despite-mid-year-pandemic-lull/

Why be accessible:

Attract more users
Improve Lighthouse metrics
Don’t get sued

A set of guidelines called WCAG (Web Content Accessibility Guidelines) are usually used to ensure accessibility compliance. This blog post will touch upon a number of most common WCAG violations.

Always add labels to inputs

Inputs should always have text associated with them explaining what the input value used for. If a label is missing, then, when focusing with a screen reader, the user will not know what the input is used for. Placeholder text cannot be used as a replacement for labels because its purpose is to show an example of a valid value. Moreover, placeholder text does not have broad support across screen readers, as noted by Web Accessibility Initiative (WAI).

<label for="html">HTML</label>
<input id="html">

Always show focus

WCAG Success Criteria 2.4.7
A web application should be entirely navigable using a keyboard. One way of doing so is by hitting the Tab key to focus across different elements of the page. When navigating like this, a clear indication of focus must be shown to indicate which element is currently focused. Not doing so affects the keyboard usability of the website.

Move focus sequentially (left-to-right, top-to-down)

WCAG Success Criteria 2.4.3
Related to making focus visible, focus should also traverse the page sequentially in a way that makes sense. In most cases, this will mean that pressing Tab moves focus left-to-right, top-to-bottom. This violation is often made by using the CSS float property which ignores the ordinary flow of the page. A common way of fixing this is switching from float to flexbox with justify-content: right.

Note that if the website is provided in a language read right-to-left, such as Arabic, then focus should move right-to-left accordingly. To see an example of this, visit this Syrian government page.

Avoid color-alone failure

Color alone cannot be used to convey information. An example of this failure would be displaying a set of badges (say a gold, silver and bronze medal) with the expectation that the user will make out the difference. Color is a stylistical CSS value which is not conveyed to a screen reader user, therefore when navigating across the badges, the user will not be able to identify which badge is gold, silver or bronze. The easiest way to avoid this failure is to ensure labels exist for the given elements. These can be visual or hidden using aria-label.

Keep sufficient contrast between text and background

WCAG Success Criteria 1.4.3
The color between text and the background must be of a sufficient contrast in order to ensure easy readability. While there are different levels of compliance to this rule, a contrast ratio of 4.5:1 is a good start that will cover most use cases. A handy way to inspect for errors in the WebAIM contrast checker. To find out more about the different levels of compliance, see the WAI page for WCAG conformance.

Do not conflict links with buttons

It is important to differentiate between the semantic meaning of links and buttons:
Links are used to navigate to a different page.
Buttons are used to trigger an action on the current page.

A common source of confusion for screen reader users is when the two elements are used interchangeably. Using a button to open an external link in a new tab is one of the most common violations of this rule.

Use modal dialogs for required input (with trapping and returning focus)

Disclosures: pop-ups that add additional information without affecting the user tab-flow.
Dialogs: pop-ups that trap user focus and force the user to perform an action.

When opening a modal that acts as a dialog, focus must be placed inside of the modal.
When closing the modal, focus must be placed back on the trigger button.

Use semantic HTML whenever possible

Make use of , , and elements to indicate the key parts of your page. If you don’t make use of these landmarks, then screen reader users may lose critical context about the section of the website they are currently on. The key advantage of using semantic HTML is that screen readers can provide quick navigation across the key landmarks of the page. To learn more, see this page for navigating landmarks with Voiceover on MacOS, and this page for using NVDA Browse Mode for Windows.

Use sufficiently large touch targets

WCAG Success Criteria 2.5.5
Use touch targets of at least 44 by 44 pixels for all interactive elements. This is especially relevant for mobile devices which have a smaller viewport. Failure on this criteria can cause frustration for mobile users and fingers are a less accurate method of input compared to a mouse.

Add a skip-to-main-content link

If your webpage has a lot of links on top, screen reader users are forced to tab through all of them before getting to the main content of the page. A handy fix for this is to provide a link that skips to the main content of the page. The link is ordinarily hidden with CSS and made visible when focusing. Clicking on the link puts focus on the main contents of the page, saving the user the hassle of tabbing.

Postman's pre-request scripts - quick authentication 🚀

Domantas Jurkus — Sat, 01 Apr 2023 14:37:13 +0000

In this post I'll share a setup that allows quickly authenticating with APIs that require credentials.

Create a new Postman collection. Informative names always help:
Inside the collection, set up a new request that requires you to have some sort of token. No surprise, the request should fail.
Inside the Postman collection, create a set of variables and set up the authentication method for the whole collection.

Click on the collection name, go to the Variables tab and create two variables: username and password. Use a dashboard account as needed.

In the Authorization tab, Select “Bearer Token“, and for the value, add {{users_api_token}}. We will generate this token next.
Let’s name our new request something like “Set Login“. On the request, go to the “Pre-request Script“ tab and add the following script:

const postRequest = {
  url: 'https://api.com/endpoint',
  method: 'POST',
  header: {
    'Content-Type': 'application/json'
  },
  body: {
    mode: 'raw',
    raw: JSON.stringify({
        "username": pm.collectionVariables.get("username"),
        "password": pm.collectionVariables.get("password")
    })
  }
};

pm.sendRequest(postRequest, function (err, response) {
    if (response.code === 200) {
        pm.collectionVariables.set("users_api_token", response.json().token);
    } else {
        pm.collectionVariables.set("users_api_token", '');
    }
});

Run your request - if everything is good, you request should go through with results returned 🚀
Best part: create a new request in the collection, The request should reuse the token saved in your collection. Just make sure that when you go to the Authorization tab for the request, the type is set to “Inherit from parent“ (which should be set by default):
The token will expire after a day, but getting a new one will be as easy as going to your “Set Login“ request and pressing Send ⬇️

React-router: composing routes

Domantas Jurkus — Fri, 09 Dec 2022 08:51:48 +0000

Let's say you are on route mysite.com/articles and the component page for this route has two links:

<Link to={'about'}>
<Link to={'/about'}>

What's the difference? The 1st link will forward to the subroute suffixed by the to argument (mysite.com/articles/about), while the 2nd link will forward to mysite.com/about.

Using <Link to={'about'}> without a leading slash is useful for going into subroutes that belong to the current route.

Of course, the routes have to be defined in your router:

<Routes>
  <Route index element={<Home />} />

  <Route path="articles" element={<Articles />}>
    <Route path="about" element={<AboutArticle />} />
  <Route />

  <Route path="about" element={<About />} />

  <Route path="*" element={<NotFound />} />
</Routes>

Managing multiple backends with webpack

Domantas Jurkus — Wed, 07 Dec 2022 08:48:20 +0000

As a frontend application becomes more mature, it often develops a need to talk to multiple backend services. Each one of those backends will likely have specific authentication, API routes and configuration which needs to be managed somewhere. One common approach for this is a backend-for-frontend pattern where a dedicated backend manages all of this for your frontend. However, if you do not have the luxury of spawning a backend just for your webapp, there are some nice options for making the setup less painfull with webpack.

webpack.DefinePlugin

This plugin will override env variables used in code with variables defined in an .env file.

    new webpack.DefinePlugin({
      'process.env': {
        API_HOST_USERS: JSON.stringify(process.env.API_HOST_USERS),
        API_HOST_BOOKINGS: JSON.stringify(
          process.env.API_HOST_BOOKINGS
        ),
        API_HOST_PARTNER: JSON.stringify(process.env.API_HOST_PARTNER),
      },
    }),

webpack dev server

The webpack dev server will provide config during development. This config will not be used in a production build.


const config = {
  ...
  devServer: {
    hot: true,
    port: 3000,
    inline: true,
    stats: 'errors-only',
    host: '0.0.0.0',
    proxy: {
      '/users-api': {
        target: process.env.API_HOST_USERS,
        changeOrigin: true,
      },
      '/bookings-api': {
        target: process.env.API_HOST_BOOKINGS,
        changeOrigin: true,
      },
      '/partner-api': {
        target: process.env.API_HOST_PARTNER,
        changeOrigin: true,
      },
    },
  },
};

CodeSandbox preview in Dev.to

Domantas Jurkus — Mon, 05 Dec 2022 08:06:17 +0000

Here's how to embed a CodeSandbox example inside of a Dev.to post:

{% codesandbox infinite-scroll-intersectionobserver-forked-grjfkp %}

And here's the result: