Forem: Alexander Vechy

CSS only list filtering, or abusing the platform

Alexander Vechy — Sun, 03 Sep 2023 12:46:48 +0000

I did something bad and I’m excited to share it.

Self-inflicted problem (as many are)

I used to ship my personal website to Vercel, which has generous free plan. However, I always wanted to use Cloudflare, especially if I plan to buy the domain there.

As my website is just a bunch of static content, with only few interactive components, I chose Astro. And if I need to add something fancy, I won't have troubles adding it. For example, "Share" button is a Preact component (even if it didn’t have to be).

However, sometimes you really want the page to be rendered server side. In my case, /feed page is a list of all articles I published and the list can get quite lengthy (if I actually keep my promise to write more). For the readers to filter the topics they are interested in, I add a list of tags to each post, with all the topics listed on the /feed page:

Each filter chip could be a link, adding a query param for filtering, like ?topic=web. Then, on the server, I would read the param and filter the feed:

/* Server only */
const topic = Astro.url.searchParams.get("topic");

// returns ALL articles
const feed = await getFeed();

const filteredFeed = topic
  ? feed.filter((post) => post.data.tags.includes(topic))
  : feed;

// create a flat list of all unique tags used
const topics = [...new Set(feed.flatMap((post) => post.data.tags))];

No client JavaScript, and thanks to View Transitions, visitors barely notice that the page was Server Side rendered.

Bringing solution to the problem that doesn’t exists; get two more problems

As I switched from Vercel to Cloudflare, I immediately noticed the major problem: my images are not optimised. astro:assets provide image optimisations using Sharp, and Cloudflare adapter does not support it (maybe only for now?). So, I was left with the choice of:

manually optimise images every time;
do not optimise images;
do not SSR, build the page at build time with all the content, apply filtering client side;

As first two options are not to my liking, I thought what I can do with the last one.

Obviously, I could just remove tags filtering and nobody would notice. But hey, we’re engineers here, and we like the challenge.

First quick solution is to add filtering through JavaScript, we all did that:

get a list of articles and tags as JSON from the server;
pass it to a component that keeps track of selected chips and renders a list;
react to chips selection to filter the list;

This seems like a trivial task for any web framework. With Svelte I could even avoid shipping lots of JavaScript. But hey, we’re engineers here, and we like the challenge.

Solution

I knew I can just render all articles and then hide those not matching filtering with display: none. I also knew I could toggle that with :has CSS selector. So, I need:

a list of checkboxes with a value corresponding to each tag

<form>
  <input type="checkbox" value="react" />
  <input type="checkbox" value="tailwindcss" />
</form>

hide all articles when one of the checkboxes is checked (filtering applied)

/* if any of the checkboxes is selected, hide all articles */
.feed:has(> form input:checked) .feed-entry {
  display: none;
}
/* TODO: put display: block to those matching selected checkboxes */

Show the articles matching the filter

Show the articles matching the filter

This last point is the most complex. As the list of tags and articles is dynamic, I couldn’t just list all of them in CSS, but I knew I need something like this:

.feed:has(> form input:where(
  /* list of all article tags */
  [value=react]:checked,
  [value=tailwindcss]:checked
 ) matching-article  { display: block; }

I decided to go with a straightforward approach: generate <style> tag with each article rendered:

/* for each post, take it's slug as id */
const id = `entry-${post.slug}`;
/* form a CSS selector */
const css = /* CSS */ `
.feed:has( > form input:where(
    ${post.data.tags.map((tag) => `[value="${tag}"]:checked`).join(",")})
) #${id} { display: block; }`;

return (
  <>
    <style set:html={css} />
    <li>
      <a href={post.slug}>{post.title}</a>
    </li>
  </>
);

Now, each article would include both, the UI and the <style> tag which makes it visible when correct checkboxes are selected.

P.S. Again, any Web framework would solve this better. You would ship less code in general, as instead of repeated HTML for each article, you only ship template for what JS should generate at runtime. Especially for this functionality, the risk of JS being disabled or failed to load can be neglected completely.

Resetting the state

As the visitors select multiple chips, we want them to be able to reset the selection to see all articles again. The solution is quite simple: reset input/button:

<form>
  /* style same way as the rest of the chips */
  <input type="reset" />
  <input type="checkbox" value="react" />
</form>

Sprinkles

The CSS shipped with every article could be optimised, to ship less code. As the list is rendered fully at build time, I leverage lightning fast lightningcss:

import { transform } from "lightningcss";

// in each article
const { code } = transform({
  code: Buffer.from(/* CSS */ `
    .feed:has( > form
    input:where(${post.data.tags
      .map((tag) => `[value="${tag}"]:checked`)
      .join(",")}
    )) #${id} { display: block; }
  `),
  minify: true,
});
return (
  <>
    <style set:html={code} />

Would also be nice to add view transitions to smoothly animate list items appearing and disappearing. Something like:

<form
  onchange="document.startViewTransition()"
  onreset="document.startViewTransition()"
>

This doesn’t work, however, as the list items display is changed before the snapshot is taken? Not sure.

Summary

You can play around with the final result on this deployment:

https://1f1e705a.alvechy.pages.dev/feed

As I said, it was a challenge rather than a final solution. What you should be doing instead?

ship JavaScript;
leverage the server. For example, with little bit of JavaScript, you can achieve lazy loading of the feed as user scrolls, instead of shipping huge HTML as is;
ship more rounded corners;

Maximizing the benefits of Tailwind

Alexander Vechy — Sun, 26 Mar 2023 18:22:41 +0000

Around a year ago I was building a component library for my personal projects – Fxtrot UI. Learn once – use everywhere. Regardless the idea I have, I don't need to think again what I should use for building the UI.

At the time, I already had the stack I believed in, using CSS-in-JS library stitches. It provides a great DX with theming, variants for class names mappings and all that is type-safe.

const Button = styled('button', {
  variants: {
    tone: {
      primary: {
        backgroundColor: '$primary',
      },
      success: {
        backgroundColor: 'green',
        borderColor: 'green'
      },
      danger: {
        backgroundColor: 'red',
      }
   }
});

// tone is a prop with correct suggestions, mapping to correct className
<Button tone="primary" />

While I still believe it was a good choice, things tend to change:

the plan to generate atomic CSS classes was abandoned (not lightly);
React 18 brought some concerns for CSS-in-JS libraries;
the team behind stitches, Modulz was aquired by WorkOS, putting its OS projects at question;
adding important functionality, like static extraction, to stitches was hence paused;

I won't repeat after others, but producing CSS at runtime is both, client overhead and just not needed. There is no purpose for your CSS to be that dynamic. stitches showed how a good DX can look like, and tools like Vanilla Extract also provided the convenience of a similar API for components variants through Recipes package:

import { recipe } from '@vanilla-extract/recipes';

export const button = recipe({
  base: {
    borderRadius: 6
  },

  variants: {
    color: {
      neutral: { background: 'whitesmoke' },
      brand: { background: 'blueviolet' },
      accent: { background: 'slateblue' }
    },
    size: {
      small: { padding: 12 },
      medium: { padding: 16 },
      large: { padding: 24 }
    },
    rounded: {
      true: { borderRadius: 999 }
    }
  },
})

Even more, working with plain CSS at Skyscanner reminded me how awesome the experience could be, both, in editor intelligence and CSS freedom. It made me think how alienated it actually is to write JS objects for CSS:

const style = {
  [`${otherStyle} &`]: {
    backgroundColor: 'white'
  }
}

So, the requirements were pretty simple:

Be able to write plain CSS.
Allow configurable theming.

To me, this reads as "just use plain PostCSS with CSS variables".

There are two worlds

What I noticed pretty early building my components in plain CSS is how difficult it became combining them into useful UI elements.

Before:

<Box p="4">
  <Row gap="4">
    <Button>Save</Button>
    <Button>Cancel</Button>
  </Row>
</Box>

After:

import STYLES from './Styles.module.css';

<div class={STYLES.container}>
  <Row gap="4">
    <Button>Save</Button>
    <Button>Cancel</Button>
  </Row>
</div>

I migrated Row element that would cover most common layout composition with flexbox, but I still had to create a CSS file every time I need to do something "out of the box", something that component library does not provide.

Another thing I noticed working on big production systems, is that Design System implementation CSS has different concerns from the actual product CSS. Design System CSS is all about consistency, flexibility and maintainability. It often requires complex selectors like:

&:where(:focus-within, :hover):not(:disabled) {
  background: var(--colors-primary);
}

The consumer of such Design System will rather be concerned about composing those UI components and providing the layout layer:

.container {
  display: flex;
  align-items: center;
  gap: var(--spacing-4);
}

And that's great. I wouldn't want product features to include any complex CSS. If there's a need to write an interactive element with effect on :hover, maybe there should be a primitive in Design System for that instead, like <Hoverable>? Otherwise, they could miss that :hover styles should probably be also applied when the element has focus, for keyboard users.

Coming from CSS-in-JS and Styled System, I truly believe that a perfect Design System provides developers all the primitives to build UI without writing any CSS, but as a composition of primitives and their props.
So instead of:

<div className={STYLES.container}>
  <div className={STYLES.cardWrapper}>
    <Card className={STYLES.changePaddingBecauseThisUseCasesNeedsADifferentOne}>
      <Content />
    </Card>
    <Button>Cancel</Button>
  </div>
</div>

We could work with:

<Box p="2">
  <Column gap="2">
    <Card>
      <Box p="4">
        <Content />
      </Box>
    </Card>
    <Button>Cancel<Button>
  </Column>
</Box>

First, it's expressive. You can already imagine that a Box provides some padding, Column will render a Card and a Button in a column, with a gap in between. All this without looking at the separate .css file.

My thinking at this point was pretty narrow already. I don't want another CSS-in-JS for a Box component, but I do want to provide devs a simple way to collocate styles with the markup.

Becoming a cautious fan of Tailwind

As I was already interested in TailwindCSS, and the community was visible and strong, it finally clicked for me why people liked it so much:

<div class="p-2">
  <div class="flex flex-col gap-2">
    <Card class="p-4">
      <Content />
    </Card>
    <Button>Cancel</Button>
  </div>
</div>

This is expressive! With good setup and a component library, developers are enabled to leverage all the benefits promised by TailwindCSS:

The ultimate aim of the Design System has become to empower developers with a suite of accessible building blocks, allowing them to efficiently craft interfaces that are both scalable and consistent.

TailwindCSS is not for building component libraries

The first thing I saw immediately was the reason people don't like Tailwind. Writing a component library using plain Tailwind classes on primitives just does not scale, class names get too long, sharing the styles becomes questionable (or repeatable), you are restricted in selectors by Tailwind's syntax:

const button = css({
  variants: {
    tone: {
      action: 'bg-primary hover:bg-primary/80 hover:border-primary focus:bg-primary/80 focus:border-primary text-on-primary ',
      danger: 'bg-red/70  hover:bg-red/80 hover:border-red focus:bg-red/80 focus:border-red  text-white',
      success: 'bg-green/70  hover:bg-green/80 hover:border-green focus:bg-green/80 focus:border-green text-white',
    }
  }
})

This is a simple example, but there's no way it's more maintainable than just CSS:

.button {
  display: flex;
}
.button-tone--action {
  background-color: theme(colors.primary);
  &:where(:hover, :focus) {
    background-color: theme(colors.primary/0.8);
    border-color: theme(colors.primary);
  }
}
.button-tone--danger {
  background-color: theme(colors.red);
  &:where(:hover, :focus) {
    background-color: theme(colors.red/0.8);
    border-color: theme(colors.red);
  }
}

It's more code, but that's the point. I believe that a general rule for Front End development should be: be more explicit in your source if it does not affect the resulting build. And unless you work with monorepo or ship your component library pre-transpiled, you won't gain much from using plain Tailwind classes.
Explicit approach also benefits heavily from being able to use native CSS features, like @container queries or @layers support without waiting for TailwindCSS to implement them.

Another thing you could notice is that I chose not to use Tailwind's @apply:

.button {
  @apply flex;
}
.button-tone--action {
  @apply bg-primary;
  &:where(:hover, :focus) {
    @apply bg-primary/80 border-primary;
  }
}

First, the same general rule for Front End development applies: don't be implicit if it doesn't bring any benefits. Both classes will produce same CSS, but second is more explicit and is very easy to read, understand, modify, move away from TailwindCSS.

Second, one of the creators of TailwindCSS regrets himself about the introduction of @apply:

The result

I truly believe that a good design system is essential for the velocity of application development. Wrong tools or abstractions will eventually lead to slow delivery or a huge burden on the users of the app. TailwindCSS is the right choice, with great ecosystem for building web applications while not imposing non-platform features:

Tailwind Configuration file allows you to impose the rules. For example, adding CSS Logical Properties or theming through CSS variables;
You can (and sometimes should) just use plan .css files with theme syntax, to leverage Tailwind's styles consistency, but be closer to the platform;
TailwindCSS VS Code extension provides autocomplete for theme(spacing.2) syntax in CSS, or when writing classNames;

Fxtrot UI is an accessible* React component library that supports theming and provides a TailwindCSS plugin for the consumers of the lib to write consistent UIs.

Creating API for components: flexbox layout

Alexander Vechy — Fri, 07 May 2021 22:26:59 +0000

How many times did you write display: flex? This goes so common that some people tried applying display: flex to almost all elements on the page.

In this post we will go through the thoughts process behind the API decisions for the most used component.

I've been thinking to write this for a while as I continue to see different implementations of a flexbox component, each with own API. I think we should stop inventing and standardize this.

xkcd: Standards (https://xkcd.com/927/)

Start

In this article I'm going to use React and stitches (I am still in love with it). But the main idea of this article is to justify the API decisions that can be then applied in Vue, Svelte, Lit, or any other front-end tool.

Let's start simple:

import { styled } from '@stitches/react'

export const Flex = styled('div', {
  display: 'flex',
})

For the sake of simplicity, I'm using pre-configured styled directly from stitches, but I in your libraries I encourage to use theme tokens for consistent layout properties, colors, font sizes, etc.

Wrapping

Let's start simple and add flex-wrap control:

import { styled } from '@stitches/react'

export const Flex = styled('div', {
  display: 'flex',
  variants: {
    wrap: {
      'wrap': {
        flexWrap: 'wrap',
      },
      'no-wrap': {
        flexWrap: 'nowrap',
      },
      'wrap-reverse': {
        flexWrap: 'wrap-reverse',
      },
    },
  },
})

I'm using stitches variants that produce nice TypeScript props for Flex component

That was the simplest API decision to make, we only removed flex word to avoid repetitiveness, because all props exist in the context of Flex element already. Bear in mind, that the default browser value is nowrap, so using <Flex wrap="wrap"> can be a common thing. Although it might feel weird, it's still easier to learn and use (like flex-wrap: wrap), comparing to a made-up API.

Flow direction

Let's move on to the second prop: flex-direction.
I've seen direction used in some Design Systems, but for some people (me) it can be even worse than writing cosnt, especially because it's a commonly used prop.
Other Design Systems incorporate Row and Column components – they provide great context for the consumer:

// Flex defined as before

export const Row = styled(Flex, {
  flexDirection: 'row',
})

export const Column = styled(Flex, {
  flexDirection: 'column'
})

Although now we also need to handle the cases when we want to use flex-direction: row-reverse; // or column-reverse. So, we either add reverse boolean prop (since it's not a common prop to be used):

// Flex defined as before

export const Row = styled(Flex, {
  flexDirection: 'row',
  variants: {
    reverse: {
      true: {
        flexDirection: 'row-reverse'
      }
    }
  }
})

export const Column = styled(Flex, {
  flexDirection: 'column',
  variants: {
    reverse: {
      true: { // neat way to create boolean variants in stitches
        flexDirection: 'column-reverse'
      }
    }
  }
})

... or we define flow direction directly in the Flex component:

export const Flex = styled('div', {
  display: 'flex',
  variants: {
    wrap: {}, // defined as before
    flow: {
      'row': {
        flexDirection: 'row',
      },
      'column': {
        flexDirection: 'column',
      },
      'row-reverse': {
        flexDirection: 'row-reverse',
      },
      'column-reverse': {
        flexDirection: 'column-reverse',
      },
    },
  },
})

As you might know, flex-flow is a shorthand for flex-direction and flex-wrap, so we're not making up the API again, but adopting it.

The usage so far would be (overriding browser defaults):

<Flex flow="row-reverse" wrap="wrap" />
<Flex flow="column" />
// or with dedicated components
<Row reverse wrap="wrap" />
<Column />

Which API you like the most is up to you, both of them work great. I would prefer having just Flex or having all 3 of them. Flex itself is easy to maintain and it provides enough context straight away looking at flow prop, especially when it needs to change based on screen size, using response styles:

<Flex flow={{ '@tablet': 'row', '@mobile': 'column' }} />

Imagine doing this with dedicated Row and Column components.

Alignment

So, making quite a good progress here, let's move on to the most interesting part: alignments.
While the official API for this would be to use justify-content and align-items, I always thought that both of these words make little sense to me when writing CSS. Maybe it's because I'm not a native English speaker, or maybe they don't make much sense when thinking about flex boxes.

One of the greatest articles that helped me to understand these properties was A Complete Guide to Flexbox (most of us still referring to). It has awesome visualizations that show how these properties affect items positions by the change of what is called main axis and cross axis. What really helped me though, was flutter's Flex widget. It has these two awesome attributes: mainAxisAlignment and crossAxisAlignment and the usage is:

Flex(
  mainAxisAlignment: MainAxisAlignment.spaceEvenly,
  crossAxisAlignment: CrossAxisAlignment.end,
)

What's really great about this API, is that it's really easy to visualize in your head. If you have a row, your main axis is horizontal, if you have a column, it is vertical. So, no matter the direction, you can imagine your items evenly spaced on the main axis and aligned to the end of the container on the cross axis.

CSS-tricks: Directions (https://css-tricks.com/snippets/css/a-guide-to-flexbox/#flex-direction)

Knowing this, we can incorporate new API into our own component:

export const Flex = styled('div', {
  display: 'flex',
  variants: {
    wrap: {},
    flow: {},
    main: {
      'start': {
        justifyContent: 'flex-start',
      },
      'center': {
        justifyContent: 'center',
      },
      'end': {
        justifyContent: 'flex-end',
      },
      'stretch': {
        justifyContent: 'stretch',
      },
      'space-between': {
        justifyContent: 'space-between',
      },
    },
    cross: {
      start: {
        alignItems: 'flex-start',
      },
      center: {
        alignItems: 'center',
      },
      end: {
        alignItems: 'flex-end',
      },
      stretch: {
        alignItems: 'stretch',
      },
    },
  },
})

Comparing to flutter's Flex API, I shortened mainAxisAlignment to main and crossAxisAlignment to cross. While TypeScript provides great autocomplete experience, seeing these long property names when composing multiple Flex components was hurting my eyes. Since both of the properties exist in the context of Flex component, I believe it's enough to understand them.

Now, the usage would be:

<Flex flow="column" main="space-between" cross="center" />

The thought process for this component is fairly easy (or the one you can get used to): it's a column, so items will be evenly distributed across the main axis (y), and across axis x they will be centred.

By the way, new Chrome Dev Tools flexbox visual debugging is awesome.

Spacing

Now, the last prop we need to add is the one that controls spacing between the child elements. There were two approaches, generally: no-side-effects-but-nested-divs-one which wraps every children into box with negative margins to allow proper wrapping behaviour without changing the child nodes styles, and flex-gap-polyfill one, that changes the styles of its children through > * selector. Gladly, we don't need to talk about them today, since Safary 14.1 was the last one among the big folks to be released with the support of flexbox gap property. Thankfully, Apple is quite pushing in regards to updates, so we can see global browser support growing pretty fast.

export const Flex = styled('div', {
  display: 'flex',
  variants: {
    // the rest of the variants
    gap: {
      none: {
        gap: 0,
      },
      sm: {
        gap: '4px',
      },
      md: {
        gap: '8px',
      },
      lg: {
        gap: '16px',
      },
    },
  },
})

Few things to comment here. First, you can still use pollyfilled option here, see an example from an awesome Joe Bell. Second, use xs, sm, etc tokens only if they are already incorporated in your Design System, otherwise, you may consider TailwindCSS number-tokens instead. Third, we don't implement powerful row-gap and column-gap CSS properties, but you can do them same way as for the gap. Third, we keep 'none' option to be able to set gap conditionally in a clear way, for example through @media breakpoints: gap={{ '@desktop': 'none', '@tablet': 'lg' }}.

End

And that's it! I really hope that more and more people would start seeing their UIs as a composition of layout and interactive elements, writing very little of CSS.

You can see some usage examples here. As with many things, you get the taste in the process, so feel free to play around with the playgrounds, see how such props help your intuition with visualizing the items.

Full example

import { stlyed } from '@stitches/react'

export const Flex = styled('div', {
  display: 'flex',
  variants: {
    wrap: {
      'wrap': {
        flexWrap: 'wrap',
      },
      'no-wrap': {
        flexWrap: 'nowrap',
      },
      'wrap-reverse': {
        flexWrap: 'wrap-reverse',
      },
    },
    flow: {
      'row': {
        flexDirection: 'row',
      },
      'column': {
        flexDirection: 'column',
      },
      'row-reverse': {
        flexDirection: 'row-reverse',
      },
      'column-reverse': {
        flexDirection: 'column-reverse',
      },
    },
    main: {
      'start': {
        justifyContent: 'flex-start',
      },
      'center': {
        justifyContent: 'center',
      },
      'end': {
        justifyContent: 'flex-end',
      },
      'stretch': {
        justifyContent: 'stretch',
      },
      'space-between': {
        justifyContent: 'space-between',
      },
    },
    cross: {
      start: {
        alignItems: 'flex-start',
      },
      center: {
        alignItems: 'center',
      },
      end: {
        alignItems: 'flex-end',
      },
      stretch: {
        alignItems: 'stretch',
      },
    },
    gap: {
      none: {
        gap: 0,
      },
      sm: {
        gap: '4px',
      },
      md: {
        gap: '8px',
      },
      lg: {
        gap: '16px',
      },
    },
    display: {
      flex: {
        display: 'flex',
      },
      inline: {
        display: 'inline-flex',
      },
    },
  },
})

Key takeaways:

keep the API as close to the official specs as possible, making it easy to learn
make up own API is possible, but maybe there's some solution that is fairly common and people are used to it
learning other tools, like Flutter can open new perspectives

Making your React component library meaningful in 2021

Alexander Vechy — Sun, 13 Sep 2020 18:19:04 +0000

In the last article we managed to setup our project:

use dokz as a documentation engine
add stitches as a class names generator and manager of class names on components

Now, we're going to use:

typescript to leverage type-safe tokens and props for our component library
@react-aria to make our components accessible

TypeScript

I'm not going to talk about the benefits of using TypeScript in this article, but I would say that [unfortunately], when your library is super awesome already, this is the only way forward to make it even more enjoyable. And we know our library is going to be the best, so we can start with TypeScript straight away:

yarn add --dev typescript @types/react

And create a tsconfig.json (most of the stuff is added by next, the base config was copied from here)

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "sourceMap": true,
    "strict": true,
    "esModuleInterop": true,
    "types": ["react"],
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "noEmit": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  },
  "include": ["next-env.d.ts", "lib", "pages"],
  "exclude": ["node_modules"]
}

Now we rename our lib/*.js files to .ts(x) and we're done with the migration. We can now check that we get autocomplete suggesting possible values that we defined in our stitches.config.ts:

Accessibility

Building accessible application is as important as having an elevator in the 9 stories building. You can skip building it, but you will hate yourself, people will hate you, and adding it to the existing building is... Well, at the very least is just expensive.

If you want to get familiar with the topic and don't really like to read specifications, I encourage you to read Accessible to all on web.dev.

But if you were ever wondering "Why do we need to do it ourselves? Why it's not built into the platform, if the standards are defined?", well, let's discuss it in the comments, I think we're just not there yet. I hope we will get some new API similar to how Date gets improved or how Intl gets new features.

Before the future comes, we can use a "library of React Hooks that provides accessible UI primitives for your design system" from react-aria. This is the simplest way you can take to make your components accessible while keeping your business satisfied with the speed of delivery.

Let's start from the Button component. First, we add simple lib/Button.tsx:

import React from 'react';

import { styled } from '../stitches.config';

const ButtonRoot = styled('button', {
  py: '$2',
  px: '$3',
  bc: '$blue500',
  color: 'white',
  fontSize: '14px',
  br: '$sm',
});

const Button: React.FC = ({ children }) => {
  return <ButtonRoot>{children}</ButtonRoot>;
};

export default Button;

One of the downsides of CSS-in-JS solutions is that you have to come up with even more variable names, like ugly ButtonRoot

Let's now create a playground for our Button to see it in action. Create pages/components/Button.mdx and add simple playground code:

---
name: Button
---

import { Playground } from 'dokz';
import Box from '../../lib/Box';
import Button from '../../lib/Button';

# Button

<Playground>
  <Box css={{ p: '$8' }}>
    <Button>Hello</Button>
  </Box>
</Playground>

Box is just for offset for now

So here's what we have:

Now let's add our first react-aria package:

yarn add @react-aria/button

And use it in our lib/Button.tsx:

import React, { useRef } from 'react';
import { useButton } from '@react-aria/button';

import { styled } from '../stitches.config';

const ButtonRoot = styled('button', {
  py: '$2',
  px: '$3',
  bc: '$blue600',
  color: 'white',
  fontSize: '14px',
  br: '$sm',
});

const Button: React.FC = (props) => {
  const ref = useRef<HTMLButtonElement>(null);
  const { buttonProps } = useButton(props, ref);
  const { children } = props;

  return (
    <ButtonRoot {...buttonProps} ref={ref}>
      {children}
    </ButtonRoot>
  );
};

export default Button;

Here, I'm just following the official instructions and I always encourage people to go to the docs directly and copy code from there than from the article. Just remember that code in the Internet isn't 100% valid unless taken from the official docs (then it's a least 90% valid)

Okay, this looks simple. What we've achieved? Actually, a lot. I'm pretty sure it's hard to buy the benefits when you don't know the context. So, if you're interested why you need all this code, why we need to handle "press management" on the button, I would suggest to read more in-depth articles by the author of the react-aria: Building a Button.

Now, let's try this in the playground:

<Button onPress={() => alert('Wow')}>Make Wow</Button>

Now let's make sense out of our CSS-in-JS solution and create few button variants. I will use Tailwind CSS as a reference:

const ButtonRoot = styled('button', {
  py: '$2',
  px: '$3',
  color: 'white',
  fontSize: '14px',
  fontWeight: 'bold',
  transition: '0.2s ease-in-out',

  variants: {
    variant: {
      default: {
        'bc': '$blue500',
        'color': 'white',
        'br': '$md',
        '&:hover': {
          bc: '$blue700',
        },
      },
      pill: {
        'bc': '$blue500',
        'color': 'white',
        'br': '$pill',
        '&:hover': {
          bc: '$blue700',
        },
      },
      outline: {
        'bc': 'transparent',
        'color': '$blue500',
        'border': '1px solid $blue500',
        'br': '$md',
        '&:hover': {
          bc: '$blue700',
          borderColor: 'transparent',
          color: 'white',
        },
      },
    },
  },
});

This will create a mapping between prop variant and set of class names to be assigned to the button component. You may notice that some styles are repeated between variants. This is where I would strongly suggest to block any thoughts about extracting common styles into separate variables to make code DRY. Allow variants to be isolated unless you feel the need to extract something.

Now, when we have our variants defined, how do we use in our Button component? Well, with some tricks:

const ButtonRoot = styled('button', {
  /* common styles */

  variants: {
    variant: {
      default: { /* styles */ },
      pill: { /* styles */ },
      outline: { /* styles */ },
    },
  },
});

type Props = React.ComponentProps<typeof ButtonRoot>;

const Button: React.FC<Props> = ({ as, variant = 'default', ...props }) => {
  const ref = useRef<HTMLButtonElement>(null);
  const { buttonProps } = useButton(props as any, ref);

  return (
    <ButtonRoot {...buttonProps} variant={variant} as={as} ref={ref}>
      {props.children}
    </ButtonRoot>
  );
};

First, we infer types generated by stitches:

type Props = React.ComponentProps<typeof ButtonRoot>;

This allows us to get access to defined variant prop and as prop that stitches provides to overwrite the HTML Element to render (BTW, you may argue whether you want this prop to be available for Button or it's better to create a new component to handle specific case, for example for <a> HTML element that looks like a button).

Second, we use this type for our Button, for the consumers of this component to see what props are available, specifically what variant one can apply:

const Button: React.FC<Props> = ({ as, variant = 'default', ...props }) => {

We also extract props that aren't default to <button> element, just to make things clear. variant prop gets default variant (you can use Button.defaultProps also for that).

Then, we shamelessly use any:

const { buttonProps } = useButton(props as any, ref);

It's not the first and not the last time we have to use it. But when you deal with types that aren't first-class citizens in the language, chances are that even describing same thing can be done in different way. In this case, onFocus prop expected by useButton doesn't match with onFocus prop that stitches has in its type definitions for button. But since we know it's <button> and we expect people to pass only button props – we can allow ourselves to use any this time.

Let's see these variants in pages/components/Button.mdx:

---
name: Button
---

import { Playground } from 'dokz';
import { Box, Button } from '../../build';

# Button

<Playground>
  <Box css={{ p: '$8', display: 'flex', gap: '$3' }}>
    <Button onPress={() => alert('Wow')}>Make Wow</Button>
    <Button variant="pill" onPress={() => alert('Wow')}>
      Make Wow
    </Button>
    <Button variant="outline" onPress={() => alert('Wow')}>
      Make Wow
    </Button>
  </Box>
</Playground>

Saving, waiting a moment and...

Here we go!
If you want to test props autocomplete (unfortunately mdx is not supported yet), try to write simple component even inside lib/Button.tsx that uses this Button component. You'll see inferred possible variants you can pass to the component:

So now we used some benefits of stitches and react-aria packages. I encourage you to check out more react-aria packages and see what else you can do with stitches, for example, how you can easily change the layouts based on the window size using responsive styles.

Next, we are going to build and deploy the docs and the library, so that our foundation for component library is complete and we can start building more components.

Developing React component library in 2021

Alexander Vechy — Sat, 12 Sep 2020 15:24:44 +0000

In the previous article we've made our decisions on the tools we going to use for our new React component library. Let's recap:

we use stitches as our CSS-in-JS solution
dokz will power our documentation website
react-aria helps with accessibility
and Vercel will host all that

Assuming we already have a nice name and repository inside our organization, let's start from the documentation engine:

❯ yarn create dokz-app
yarn create v1.22.5
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...

success Installed "create-dokz-app@0.0.6" with binaries:
      - create-dokz-app
✔ What is your project named? … awesome-ds

This will quickly create folder structure and add required dependencies to package.json. dokz is built on top of Next.js, hence folder structure may seem familiar to you. If not, I encourage you to try Next.js on your own as it's so awesome that I don't want it to outshine this article's main purpose.

You can now install the dependencies and verify that it works:

yarn install

yarn dev

And we see it on http://localhost:3000/!

Awesome, let's move on. Now we need to add stitches and try it out. As I mentioned in the previous article, the setup is super simple. Stop the server first and execute:

yarn add @stitches/react

And we're good to go! Let's create next two files: lib/stitches.config.js and lib/Box.js so that our fodler sturcutre is similar to:

awesome-ds
└───.next  
│
└───lib
│   │   Box.js
│   │   stitches.config.js
│   
└───node_modules
│   
└───pages
|   ...

Here I'm pushing two conventions: keep sources of the component library in lib folder (as it's shorter than components) and use PascalCase for React component names, as it's mentally easier to see that Box.js is a React component while box.js would be some utils file, not related to React.

stitches.config.js is where we create a styled function:

import { createStyled } from '@stitches/react';

export const { styled, css } = createStyled({});

Here, we export styled and css returned by createStyled. This might seem inconvenient, as wouldn't it be easier to use:

import { styled } from '@stitches/react'

But my take on this is that it's not only allows to have multiple instances of styled for whatever reason, but it also provides a nice way for TypeScript autocomplete. We will cover it later.

createStyled takes a configuration object we should use to make our design system to be a consistent system. If you're familiar with styled-system, then this library has it out of the box. It allows us to define reusable variables that will be replaced at runtime with defined values, common colors, consistent spacing, font sizes, etc. So, we start from tokens:

export const { styled, css } = createStyled({
  tokens: {
    colors: {
      $text: '#1A202C',
      $textLight: '#718096',
      $background: '#FFF',
      $accent: '#ED8936',
    },
    space: {
      $0: '0px',
      $1: '4x',
      $2: '8px',
      $3: '12px',
      $4: '16px',
      // etc
    },
    fontSizes: {
      $xs: '12px',
      $sm: '14px',
      $base: '16px',
      $lg: '18px',
      $xl: '20px',
    },
  }
});

Here I used space scaling and colors from Tailwind CSS as I really love it. And now let's see how it works. Going to Box.js we create a simple component:

import { styled } from './stitches.config'

export const Box = styled('div', {
  // here we could define our custom styling if we needed to
})

Oh wow, I'm really impressed. That's all we need to create the main building block of a component library! This simple component now accepts css property to be styled using our created config. Let's see how it works. Go to pages/index.mdx and let's leave only Playground for us to write some code:

---
name: Getting started
---

import { Playground } from 'dokz';
import { Box } from '../lib/Box';

## Box

<Playground>
  <Box
    css={{
      backgroundColor: '$text',
    }}
  >
    <Box as="p" css={{ color: '$accent' }}>
      Holy Moley!
    </Box>
  </Box>
</Playground>

Saving, starting the docs server with yarn dev and see:

That was easy. And you may ask "but how is it different from using style prop on just div? Well, as you can see, we use our defined tokens for colors and can expand it to font styles, spacing, border radiuses, z-indicies – everything that forms a design system!

We also know that we will use some properties very often, let's make them easier to use via stitches utils:

export const { styled, css } = createStyled({
  tokens: {
   // our defined tokens
  },
  utils: {
    p: () => value => ({
      paddingTop: value,
      paddingBottom: value,
      paddingLeft: value,
      paddingRight: value,
    }),
    px: () => value => ({
      paddingLeft: value,
      paddingRight: value,
    }),
    py: () => value => ({
      paddingTop: value,
      paddingBottom: value,
    }),

    bc: () => value => ({
        backgroundColor: value
    })
  }
});

Now we can use it on our docs page to see how it works:

<Playground>
  <Box
    css={{
      bc: '$text', // instead of long backgroundColor
    }}
  >
    <Box as="p" css={{ color: '$accent', px: '$4' }}>
      Holy Moley!
    </Box>
  </Box>
</Playground>

And that's it. We can use consistent spacing and colors in any of our components! utils is very powerful, use it for the properties you want to short-hand. For example, font can produce font-size, letter-spacing, line-height and font-family to fit for every need. Or maybe you want to do yAlign: '$center' to center your content vertically.

Note on usage

As you saw in our example, we inline objects passed as css prop. Opposite to many other CSS-in-JS solutions, this won't be extracted during build time. This means that css objects will be recreated on every component render. This won't be a problem for small applications, but I suggest to build useful habits even starting small, especially when it's that simple:

const styles = {
  wrapper: {
    bc: '$text',
  },
  text: { color: '$accent', px: '$4' },
};
const ConsumerComponent = () => (
  <Box css={styles.wrapper}>
    <Box as="p" css={styles.text}>
      Holy Moley!
    </Box>
  </Box>
);

Another apprach would be to use styled function to compose class names. This will create a new component that will manage the class names passed as a className prop to the styled component itself:

const Wrapper = styled(Box, {
  bc: '$text',
})

const Text = styled(Box, {
  color: '$accent',
  px: '$4'
})

const ConsumerComponent = () => (
  <Wrapper>
    <Text as="p">
      Holy Moley!
    </Text>
  </Wrapper>
);

Alright, this looks good to me, now we move can move on to the next component: Button. We are going to cover accessibility, TypeScript and see how we can bundle our components library

Choosing the right tools for React component library in 2021

Alexander Vechy — Sat, 12 Sep 2020 14:30:05 +0000

React ecosystem is huge and there is nothing wrong about it. You're free to choose the technologies you feel right for your product. But how do you choose them? Well, you have to try them all 😅

In this series I will go over some of the tools that are currently in active development and ready to accept new users. It's not a guide on how to start a new component library just now, but rather a selection of tools to keep an eye on and consider to be used in the year of 2021.

How to style in 2021?

Before we begin... We need to decide on something very important...

I worked on different Design Systems for Vue and React, with plain CSS and CSS-in-JS, and so I already formed my opinion on tools when it comes to Design Systems. It's time to admit: I like CSS-in-JS. After few months of hate I figured that the benefit of having 3rd party manager to map your props to produced styles outweighs the runtime cost. And for component library, one of the goals of which is to manage styles, you just need it.

But there are so many options to choose from:

styled-components and emotion are two well-known options, but we know there are new, improved libraries around
treat with potentially 0 runtime code, CSS is prebuilt during build time
glaze that uses treat, but with utility-first approach built-in (think Tailwind CSS – you compose classes to style an element instead of creating new classes for every case)
linaria with 0 runtime and styled-components syntax
@compiled CSS in JS smartly prebuilds your components to inject styles and use hashed class names, so 0 runtime and very fast

By this time, you probably feel that most of them promise the same. While @emotion and styled-components have the biggest userbase, all the new emerged options came from the need to have much faster runtime, doing most of the work at build time. That's why we going to pick a shiny new kid: stitches by Modulz. I liked it straight away because it's:

has all the benefits of precompiled CSS-in-JS solution (SSR-friendly, little runtime, performant)
generates atomic CSS, so your CSS won't be growing with your application scaling
has easy installation – since it manages styles at runtime, you don't need to choose between rollup or webpack, struggle with babel plugins order execution, or your CRA/Next/Gatsby setup
supports beloved styled-system-kind utils and tokens

How to write documentation in 2021

Phew, much simpler choice, innit?
Yes, but actually no.
So, what we want for sure is to use .mdx format for our docs. Because it's a maintainable and scalable format for documentation.

I guess the most popular option and a go-to solution would be storybook, it recently released major 6th version with many improvements and deprecations (goodbye knobs). It supports MDX format, plus can parse component's source file to show props table. But honestly... It's boring. We don't want people to come to our docs page, see storybook and think that we aren't serious just because we didn't invest much time into our Design System docs, as if we don't care. We do!
Docusaurus 2 is always somewhere around the corner
docz has been inactive for a while, it's worrying to start new project with a lot of deprecation warnings
React Styleguidist is the boring choice for people who just want to get job done

But we are going to chose dokz:

it looks nice out of the box
it is very customizable
it's easy to use

In the end, our choice doesn't really matter since mdxjs is a separate project all these tools use. So mdx format is portable regardless the engine that powers our documentation site.

Accessibility

I guess this the most important thing you should think of before starting a new component library.

It's cheap to start from accessible Design System and maintain it. It is extremely expensive to make your existing Design System (and hence the app that uses it) accessible.

Thing is, accessibility is hard. The knowledge isn't widespread, business is often reluctant to invest into it until customers start to complain, designers often add accessibility as an afterthought. But if we want our product to succeed, we have to think about accessibility beforehand. Let's just name a few features where our component library can help with accessibility:

use accessible colors with enough contrast
auto-assigned or forcing to assign labels and ARIA roles
make sure our components and compositions of components (Modals, Selects) are keyboard accessible

And since accessibility is not a one-shot, but rather a continuous investment, it would be nice if there was a solution for our problems that will be improved over time. And huge thanks to Adobe for releasing react-aria. It's a set of packages that helps you to make your custom components accessible! And the documentation is awesome. You not only see how to use a package, but also what it does and the benefits it provides.

Now, where do we deploy it in 2021?

I've seen many different options, but the value Vercel and Next.js provide is unbeatable. It's like you find your favorite ice-cream and you no longer want any other.

Seems like we're done here and ready to start an actual development!

5 outcomes from building a Chrome extension with Svelte

Alexander Vechy — Thu, 12 Mar 2020 17:37:11 +0000

Even though I was happy with React and a huge fun of Vue, I still wanted to check out what's Svelte and why it is so awesome. And since the best way to try a tool is by building something with it, I decided to build a small Chromium extension (actually for the awesome Microsoft Edge browser). You can find sources here and my learnings in this article.

What's Svelte?

First things first, a quick introduction of Svelte. I will cite this awesome article by @bholmesdev

So let's go over some of the main selling points for learning web development with Svelte:

It's a component-based framework with 0 extra plugins

It handles state management without all the usual cruft

It uses scoped styling without needing CSS-in-JS (so no editor extensions or wacky syntax)

It only needs a dead simple build script to get going

Hardly any files are needed in a base project

And give you some example:

The source in Svelte REPL

How's experience?

You should go over Svelte Tutorial at least once

Svelte Tutorial is an awesome place to learn everything you need to start building apps. At first, you will probably need some patience, annoyed by HTML-template helpers. For Vue fans it's avoiding the question "Why not use the same directives as Vue does?" and for React fans it's "Why to use it at all?". But keep going and you'll get to the point when the magic of Svelte makes you feel its power.
But even after the tutorial, you will need to google sometimes, for example how to spread undeclared props to the root of your component.

Initial setup

I heard already about React fatigue, which is understandable, having all these Next.js, Gatsby, Redwood, various CSS-in-JS solutions, appearing data management solutions and upcoming React features. But it's just picking the tool. With Svelte you don't have much choice but cloning the official template which uses rollup, but you can find Webpack configs as well.

However, there is no vue-cli or create-react-app alternative that hides the setup from you. If you just learn Svelte – it's okay. But as soon as you start building something, you need to dig in. And so instead of building the product straight away, maybe tweaking some plugins, you start learning rollup and how it works with Svelte, and there aren't many resources. For example, I still didn't figure out how to generate .html file with included <script>'s and <link>'s. At least in my case, I didn't find how to have css files generated by rollup-plugin-svelte listed in my custom plugin's onGenerateBundle hook (hence none of the existing plugins can't include link to css, there is no such file). I guess it's me not knowing rollup though.

I don't want much from young framework, but it's very frustrating when I want to work on my app but instead have to spend time Googling how to setup something and do not find it. Shout out to parcel, Next.js and others for making our lives easier.

`eslint` + `prettier` + `svelte` = ❓

After few attempts I didn't manage to make eslint-plugin-prettier work with .svelte files. It continuously complained on bindings in html syntax, taking it as js and so trying to add semicolons.

eslint also has no way to understand that Svelte creates magic variables for you. Here I import text, which is a writable from svelte/store and use it in my JS as $text to extract its value.

Because (citation from Svelte Tutorial):

Any name beginning with $ is assumed to refer to a store value. It's effectively a reserved character — Svelte will prevent you from declaring your own variables with a $ prefix.

Prettier itself works flawlessly, you can even setup how to arrange <script>, <style> and template blocks in .svelte files (which maybe isn't a good thing, as it's one more thing to agree with the team on)

No TypeScript yet

The popularity of TypeScript is only growing and I've been a huge fan of it. It was the first thing I've searched after scaffolding the project, but it isn't there yet. There is a proposed solution, so let's hope we will see a full support at some point.

Too late to be young

Usually, I support the appearance of new libraries and frameworks since they all bring something new and shiny, something that popular frameworks can borrow, some functionality or ideas. I liked how different CSS-in-JS solutions continuously regress to the mean in terms of features and performance, making it possible to have few final solutions at some point. The same goes to React and Vue. You can build your business logic separated from your UI and use very similar hooks (I'm sure you can write a babel plugin that will make your hooks reusable for both frameworks).
But on the field of FE frameworks you have to propose something very different, like Flutter for Web. It enables you to have native apps on many platforms. And what I love the most - you don't have to design your components and you most probably won't screw up with theming, as Flutter provides you all needed widgets.
React is making huge promises with Suspense improving end-user and developer experience. Vue.js is soon to release 3.0 with hooks and load of optimizations and features. And many other frameworks continuously improve. Svelte on the other hand is still very young and I don't see how big companies can start betting on it. Vue.js is still considered by some as a niche framework, even being extremely popular.
The issue is obvious: being young means having no usage examples, best practices, learning resources. How do I build my stores? How do I scale and reuse routes? Which component library to use? How to build an accessible Select component? How to build static pages? While all these questions will be answered and the "ecosystem" will be developed, other FE frameworks will be way ahead.

Small update on Redux usage

Alexander Vechy — Sat, 14 Dec 2019 10:54:24 +0000

So the first Redux version was developed somewhere around 5 years from now and a lot has changed since then.

Not only React improved the way our code works for the end-users but also we, as developers, changed the way we use React. Best practices come and go, leaving us with the code that other, new developers, might not understand the purpose of. Remember that PureComponent thing? That it was added in the time where everyone was obsessed with React performance before even having any issues with that? Or smart and dumb components?

// Detect dark theme var iframe = document.getElementById('tweet-579966838525792257-723'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=579966838525792257&theme=dark" }

Why those practices change is another topic, I guess more related to the way software products are developed rather than tied to React or Front End. So here I just wanted to share a few best practices I believe made Redux usage better over the years.

Folder structure

So far I've mostly seen a separation of files based on their purpose:

Then Redux Ducks came into play, making people to separate files and folders by their features or model they work with. This is a great approach suggested by the Redux Style Guide

Notice that files were separated only when the feature became too big to manage in one file. First, actions.ts were separated from index.ts file. Then came others, making the index to export createReducer only, with imported reducer and initial state. This enables to dispatch specific actions from the specific feature. Why this approach works well? I will agree with Monica Lent that constraints make software easier to maintain. In this case, we constrain code to their features.

But it never works like that in real life! Domain models are interconnected! Actions to one module can cause changes in another! That's real life!

Alright, that's correct. So how about...

Event-driven reducers

Event-driven reducers mean that instead of making action type names to describe what you want to change in the store, you describe what just happened. E.g. instead of ADD_ITEM you say ITEM_ADDED and bum your reducer now reacts to the event, that item was added to the basket. Then it means that if you want some other reducer to change the state based on this action, you just add to that another reducer one more switch clause. If you want to know more, check out this talk by Yazan Alaboudi.

And small example from Redux Style Guide

Compare this two:

{ type: "food/orderAdded",  payload: {pizza: 1, coke: 1} }

with

{
    type: "orders/setPizzasOrdered",
    payload: {
        amount: getState().orders.pizza + 1,
    }
}

{
    type: "orders/setCokesOrdered",
    payload: {
        amount: getState().orders.coke + 1,
    }
}

With more complicated examples it gets even more beneficial, not only on the code sources side, but on the cognitive load as well, perceiving your reducers not as "for this action -> update this field", but rather "when this happens -> this updates".

It's all interconnected 🔝

So you probably don't need const ADD_ITEM_TO_THE_BASKET = 'ADD_ITEM_TO_THE_BASKET';. If your store is strictly separated by domain models or features and not by your UI code, you can separate events that occur in your system by such features. So your events can look like

{ type: 'food/orderAdded', payload: { /* order info */ }
{ type: 'posts/clapped', payload: { times: 11 } }

This way your actions are safe. Logic changes, how we handle events can change as well, but events doesn't. Or at least not that often. You can read about it there.

Second, you can easily react to the event from multiple places in your store. So instead of having:

dispatch({ type: 'ADD_CLAP' });
dispatch({ type: 'SET_COMMENTS_AVAILABLE', payload: true });

you can have multiple reducers reacting to the same event:

dispatch({ type: 'posts/clapped', payload: { /* item */ });

// in your reducers

// posts.js
  case 'posts/clapped':
    return { ...state, claps: state.claps + 1 };

// comments.js
  case 'posts/clapped':
    return { ...state, commentsAvailable: true };

And so we're moving our logic to reducers, instead of making calculations in components' code, redux-thunks, or redux-sagas. We know the logic belongs to the reducer, so we move it there. You can read more about it there.

So as you can see, best practices, which enable us to write maintainable Redux store are all interconnected: with one thing you can easier do another, without sacrificing on anything. This post wasn't intended to be "look what I found", or "one more best practice in Redux". These are just simple and short rules you can incorporate (you probably did already, partially, unconsciously, because it's a natural approach) to your Redux store architecture. And there are more of these already described in Redux Style Guide, concluded by developers to make your life easier. Please, take a quick look, maybe you can find something you have question about to ask here!

Be good, smile and tell jokes to each other!

Cover image reference: React Redux Tutorial for Beginners: Simply Explained

A guide to higher salary

Alexander Vechy — Tue, 22 Oct 2019 20:38:27 +0000

To begin with, there are few things to clarify. First, I'm just a developer myself. I'm not a manager, not a head of engineering, product owner or tech lead. I'm just a developer, and that's how I see myself growing. Second, this article is not about your technical skills, but I would address it to the Middle - Senior level. At the same time, I would love to hear opinions from less or more experienced people as well. Third, I believe there is a clear rule that you get as much as you spend on your development.

You love your company and feel that you deserve to be paid more

We, as developers, live in a very comfortable situation. The software development market is so huge, that there is a constant need in our skills. There aren't many spheres of work where you can find a job that easy, where you can switch companies whenever you feel it's time to go. This constant need in the best resources available makes businesses to create a good culture inside and outside the company, to keep existing developers happy while growing and attracting new ones. Hence, I truly believe there is no way that the company you like and work for is going to pay or value you less if your skillset enables the company to grow.

So what can you do to be the one getting the promotion with ease?

Find motivation

Not for yourself (you're internally driven, aren't you?), but for your team. Try to understand through discussions the main goal you, as a team, want to achieve. What are you working for? Is it a great product? Or you like to work with each other? Maybe it's opportunities you have to learn and develop your skills? Or is it the work-life balance you have? Each of the reasons is the valid one. If you don't learn enough, then why? How can you improve it as a team? Maybe the balance isn't there, then why? How would it be possible to get the right balance or motivate the team to get over a temporary situation? Raising these questions can be quite challenging, at least morally, as in the companies people usually afraid of saying what bothers them. There are many reasons for that, including "If others are fine, why should I complain? I don't wanna look like the one who complains a lot!". Talk about your motivation, find the most motivating and demotivating points and try to solve identified issues. I believe, that it all starts from the motivation: your team performance, hence the success of the product, and as a result satisfaction with your work. And from the managerial perspective, it's pretty hard to find issues if everyone just daily, ordinary and silently does the job. When you initiate the changes, it can't be unnoticed.

Team motivation gives you more productive and joyful environment

Start listening

During Agile ceremonies, kitchen talks or in the company chat. Try to notice pain points your product, organisation, or processes have. Discuss identified ones with other people to get some opinions. Then you can discuss the issues with possible solutions on your team meetings. In the worst-case scenario when the problem is not valid, or the proposed solution isn't great, you are the one who wasn't afraid to step in and say what worries you and (as you found out) others. I'll give you quick ideas:

PR review takes too much time because of constant delays in communications - install GitHub bot to your company messenger no notify about PR changes?
code formatting constantly changes - introduce formatting on a pre-commit hook?
little knowledge sharing within the company and offices - introduce online teams hub/channel with all the resources and technologies each team uses?
etc... There are always problems to solve. Be the one who initiated it

Start thinking about the product

Some may argue that it's not always possible to come up with some bright ideas, especially in big companies, where many people work hard to identify and validate user needs. But nothing stops you from thinking about the user who uses your code. It is easier for Front End or mobile developers to have discussions with the designer about the end-user experience. For example: "This error page we show to the user can be replaced with some message, keeping the user on the page and allowing to try the same thing again or find what is wrong themselves. Or maybe we can show the page after the second attempt? Should the user click themselves, or we can try to attempt ourselves after some time?".
At the same time, I've seen many times backend developers bringing valid questions. For example, when they try out how their API is used and finding the issues just being a user of the product. Being in the core of the product or by working on the development infrastructure, engineers can bring a totally new perspective on the product they actually know a lot about. It can happen, and quite often, that product managers or designers just aren't aware of what can be done (same way they might think that something can be done). By understanding the main goal of the feature you build, the motivation behind it, you may suggest changes that nobody else just didn't think of.

Upgrade the view on the product you develop

Be a person to ask

The simplest way to put it is "be a leader". But I notice that people tend to get it a little bit wrong. In my mind, the best leader is almost unnoticed due to the whole team doing an amazing job. Yes, some people can stand out due to their nature. But what makes them stand out? What if this something can be inherited by others so that the whole team now has this "feature"? Is it knowledge about the application architecture? Then it's the duty of the leader to make sure that everyone knows how it works and how to make it better. Is it just experience? Well, others may not have it, but even the most experienced developers still learn, no decisions should be made by one person. Being a leader means to make other people grow with you, by motivating, providing assistance and directing them. Don't be afraid of being the one who points out to the issues, sharing your learnings and resources you use to learn. Be the one who spreads the knowledge from one specific person in your team to the rest of the team. If it happened to you that you asked multiple people about something before you found the answer - share this answer to the people you asked before, or with all of your team. Quick heads up in the team's chat will make a difference in the long run.

Your team is your best feedback for promotion

If you struggle to show off your knowledge, because of imposter syndrome - I feel you. It's a constant fight we have to deal with in our social world. I would highlight constant. But we can handle that. Here are the resources that helped me a lot:

Battling Imposter Syndrome By Understanding the Dunning Kruger Effect

Kaleb M ・ Apr 29 '19

#career #webdev #beginners

Three Tips for Managing Impostor Syndrome

Ali Spittel for Ladybug Podcast ・ Aug 6 '19

#career #leadership

Otherwise...

If you feel that your management doesn't follow your development and it's hard for you to get higher wages, easily look for other options outside the company. It's a clear rule that you deserve what you deserve and it's up to you to find out what you deserve through job interviews. And we will discuss it in the second part, as I need to get feedback about this article first so that the next one will be better! So leave your comments and links to the articles that can help people with developing any of these skills.

I also wanted to promote this video, as it was quite eye-opening and motivating for me:
What do we stand for? (Kind-hearted, Humble, Together)

Building global store with React Hooks

Alexander Vechy — Sun, 17 Feb 2019 22:09:10 +0000

Tere, tere, tere! In this post I will go through my case of development a global state management solution. Nothing ground breaking, just the flow of developing a suitable API for my case.

First of all, if you're unfamiliar with React Context and React Hooks, it's time to become friends with them. Also I can honestly say that even after some time of using Hooks, I still have a tab with Hooks documentation pinned (it gets updated!).

Problem statement

Knowing that all other projects started with Redux straight away, I decided to postpone writing boilerplate, creating many files, adding reselect to "dependencies". I wanted something Stupid Simple.

Before Hooks

I started without Hooks first, as I was afraid they won't be released before my product has to be released, so I had pretty straightforward setup:

const context = createContext({field: null});

class DataProvider extends Component {
    state = {
        field: null,
        otherField: { default: 'I am default' }
    }

    getField = async () => {
        const field = await api.getField();
        this.setState({ field });
    }

    render() {
        const value = { data: this.state, getField: this.getField };

        return <context.Provider value={value}>{ this.props.children }</context.Provider>
    }
}

This is a common approach, nothing special here.

I will often point out that I don't do premature performance optimisations. Like here we create new value every time field updates, so even if some consumer doesn't use data.field it still gets updated. But is it a problem?

Later, I had some contexts, which operated with more data and had more actions, so I separated context value to { data, api } (by the way it was good challenge to separate stores to a simple modules with small responsibility area!).

So my consumers looked like this:


const Consumer = ({ title }) => {
    return (
        <BooksConsumer>
            {({ data: { books }, api: { getBooks } }) => (
                <AuthorsConsumer>
                    {({ data: authors }) => <OurComponent title={title} books={books} getBooks={getBooks} authors={authors} />}
                </AuthorsConsumer>
            )}
        </BooksConsumer>
    );
};

Okay, looks ugly. And also for each context I had to repeat all the boilerplate of creation. Then I heard about hooks released soon and decided to go all in. At least to get rid of ugly (I don't think so) render functions nesting.

const Consumer = ({ title }) => {
    const {
        data: { books },
        api: { getBooks },
    } = useContext(BooksContext);
    const {
        data: { authors },
    } = useContext(AuthorsContext);

    return <OurComponent title={title} books={books} getBooks={getBooks} authors={authors} />;
};

I have Consumers wrappers around components for easier testing.

So the next problem was the boilerplate I had to write for each context. And as one smart guy said, we want to move our dynamic pattern to a function. The first idea was to simply have something like this:

function createStore(data, api) {
    const context = createContext(state);

    const Provider = ({ children }) => {
        const [state, updateState] = useState(data);
        const value = {
            data: state,
            api: wrapApi(api, updateState, state),
        };
        return <context.Provider value={value}>{children}</context.Provider>;
    };

    return [context, Provider];
}

function wrapApi(api, updateState, state) {
    return Object.keys(api).reduce((res, key) => {
        res[key] = api[key](updateState, state);
        return res;
    }, {});
}

So that the usage of it can be:


const api = {
    getBooks: (updateState, state) => async () => {
        const books = await fetchBooks();

        updateState({ ...state, books });
    },
};


const state = {
    books: [],
    notBooks: []
}

export const [BooksContext, BooksProvider] = createStore(state, api);

Now, every time we need a new context - we use one function with a simple API. Notice, that I put updateState, state into the closure of our api, so that our components can easily just call functions from api.

Fun fact: api name was chosen because it short, and not because it makes API requests 🤷🏻‍♂️.

Again, you might be tempting to make "optimisations":

const Provider = ({ children }) => {
        const [state, updateState] = useState(data);
        const value = useMemo(
            () => ({
                data: state,
                api: wrapApi(api, updateState, state),
            }),
            [state, updateState],
        ); // this
        return <context.Provider value={value}>{children}</context.Provider>;
    };

But of course it won't make things better, state will change (as we want it to), so we will need to create new value again and bind API again.

Okay, it actually seems enough already. But I wanted some debugging experience. Not that I miss redux-dev-tools or anything... I decided to go with reducer now and add some powerful debugging capabilities (console.log):

function createStore(reducer, actions, initialState) {
    const context = createContext(initialState);

    const Provider = ({ children }) => {
        const [data, dispatch] = useReducer(reducer, initialState);

        const actionCreators = bindActionCreators(actions, dispatch, data); // bind same way as before but add console.log 😅

        return <context.Provider value={[data, actionCreators]}>{children}</context.Provider>;
    };

    return [context, Provider];
}

So I could use it as:


function reducer(state, { action, payload }) {
    switch (action) {
        case SET_BOOKS: {
            return { ...state, books: payload };
        }
        default: {
            return state;
        }
    }
}

const api = {
    getBooks: (dispatch, state) => async () => {
        const books = await fetchBooks();

        dispatch({ action: SET_BOOKS, payload: books });
    },
};

const defaultState = {
    books: [],
    notBooks: [],
};
const [BooksContext, BooksProvider] = createStore(reducer, api, defaultState);

Oh mama... Looks like Redux :c

Let's simplify a bit:

function createStore(reducer, actions, initialState) {
    const context = createContext(initialState);

    const Provider = ({ children }) => {
        const reducerFn = (state, { type, payload }) => reducer[type](state, payload); // we create reducer here instead

        const [data, dispatch] = useReducer(reducerFn, initialState);

        const actionCreators = bindActionCreators(actions, dispatch, data);

        return <context.Provider value={[data, actionCreators]}>{children}</context.Provider>;
    };

    return [context, Provider];
}

And the usage would be:


const reducer = {
    [SET_BOOKS]: (state, payload) => ({ ...state, books: payload }), // or just `books` as param
};

const actions = {
    getBooks: (dispatch, state) => async () => {
        const books = await fetchBooks();

        dispatch({ action: SET_BOOKS, payload: books });
    },
};
const [BooksContext, BooksProvider] = createStore(reducer, actions);

// component

const Consumer = () => {
    const [{ books  }, { getBooks }] = useContext(BooksContext);

    // ...usage
}

Looks better. Especially with TypeScript: I have secure actions, so that you can dispatch only enum Actions which then used in reducer. But why is it better than using redux? It's not, but.

Usually, you would import some helper functions from state library, like connect form react-redux and yours action creators (maybe even with redux-thunk). Then you map your state and dispatchers to props. With current API I can just select what I need already from context, knowing what it is and where it comes from (single source), no need for file-traveling (if you don't use redux ducks). I only needed to do something... Write own Hook!

`useStore`

function createStore<D, A extends StoreActions>(
    reducer: StoreReducer<D, any>,
    actions: A,
    initialState?: D,
): Store<D, A> {
    const context = createContext<ContextValue<D, A>>([initialState, actions ? ({} as BoundStoreActions<A>) : null]);

    const StoreProvider: FunctionComponent = ({ children }) => {
                // create Reducer, use Reducer, bind actions
        const store = useStoreProvider(reducer, actions, initialState);

        return <context.Provider value={store}>{children}</context.Provider>;
    };

    const useStore: useStore<D, A> = selector => {
        const [data, actions] = useContext(context);
                 // map state and actions to anything you need (object, array, just one field)
        const selected = selector(data, actions);

        return selected;
    };

    return [context, StoreProvider, useStore];
}

And then in my component:

const BooksList = ({ authorId ) => {
    const { books, setFavorite } = useBooks((store, actions) => ({
        books: store.books.filter(book => book.authorId === authorId), // feels like selector, isn't it? 🙃
        setFavorite: actions.setFavorite,
    }));
        const authorInfo = useAuthors(store => store.authors[authorId]);

    return (
        <List>
            {books.map(book => (
                <Book key={book.id} title={book.title} author={authorInfo} />
            ))}
        </List>
    );
};

Pretty neat, isn't it?

Why I put actions to the store? It means that all my actions have to be bound every time store changes, why not just use them as normal functions, passing them to component? Like this:

// modules/books
const [BooksContext, BooksProvider, useBooks] = createStore(reducer, initialState);
// components/Books
import {getBooks, getAuthors, useBooks } from 'modules/books'

const Books = () => {
    const {books, getBooks, getAuthors } = useBooks(store => ({ books: store.data.books, getBooks, getAuthors});
     // I wrote getBooks, getAuthors 3 times :/

    // use it

So what could be done there is passing actions that I want to bind to a store and bind them in useBooks. It means that it can be any action, even unrelated to a store and hence can dispatch action type that doesn't exist in store. But at the same time it can allow to have reusable actions fro different stores, which is rare case. Also, store creation is easier now, no need to bind anything during creation. But the main thing here is that you have to import actions which have names and them take them from useBooks with either same name (which can be confusing) or make up a new name for them (which is soo tough).

What's next?

The thing is I'm already quite happy with the current solution (not types, btw, seems like I have to learn how to write them properly). It works, there is no performance issues with 9+ stores with different kind of data and purposes. But I'd like to hear your opinions and solutions, take a look at the source code, it has second proposal with example. If it's something you'd like to use and improve - you're welcome! Then I can continue working on it, add tests, examples of usage, maybe performance tweaks, like selectors, etc (not that I won't working on it, but anyway...)!

So how would you created your global stores?

Add Vue to your acknowledged stack

Alexander Vechy — Mon, 13 Aug 2018 13:09:23 +0000

TL;DR

Vue.js can't be called "same good as React" (or even "better"). React, as a code library, its tricks and architectural decisions (like Fiber or Time-slicing, Suspense and Hooks), push JS development way further than we could ever expect, it also taught me to think functional which helps a lot in writing any applications using any technology. But Vue.js approach, as for me, slightly different. It gives you focus on the product you develop rather than code you write. At the same time, I believe that 99% of projects could be developed with Vue instead of React with no differences in functionality and performance. But Vue makes you happy. It has so huge amount of small helpers, tips, and tricks, that when you try to build stuff with React again you think "Why the hell I should I write all this boilerplate over and over, and over, and over again?". Vuex is one of the core libraries (see what it means) that give you single-source-of-troth store with jeez convenient way of usage, decreasing you code-base, which leads to fewer places for bugs. vue-router is another core library, that gives you all you need with minimal setup, but very flexible if you need something complicated. I won't even mention powerful UI and UX improvements provided by transition and transition-groups in Vue out of the box, that makes any app better. Do I think that Vue is better than React? Nope, React is still more popular and blows my mind once a year (again Fiber, Suspense). But would I use React for any next project? Nope, nope, nope. With Vue.js developer experience is way better, I would rather go with it.

Let's start

Okay, I know that React developers are very busy, no time for more intro. Let's create a new Vue project:

npx @vue/cli create simple-sample

We can now select features we want in our setup:

I selected TypeScript because we like safe types, I don't need any preprocessors, because PostCSS included by default, and vuex with vue-router because those are important parts of Vue ecosystem. We want to use class syntax (yeah, it's not default) because classes are familiar and look good. So we have our setup like:

Quick dependencies installation and now we can see the project structure:

shims- just a setup for TS, to use this awesome typed JavaScript in .vue Single File Components. You probably heard about SFC already: we don't have to, but we can write our components in one file and be happy with it!
Why? Well, because your component usually is a skeleton (template), behavior (script) and look (style). So let's create our vue file in components folder* and write our component. I called it DevToHeader.vue.

(quicktip: Vetur is a Vue syntax helper for VS Code)

Quick intro to templates

Templates are valid html
if you need to bind some data to template, you use v-bind (nobody does that**, use :), e.g. :prop="{ react: 'cool' }" (same as React, :prop="true" is equal to just prop)
if you need to listen to some event, you use v-on or shortly @. e.g. @click="functionName" or feel the power of @customEvent="handlerOfThisEventName" or @click="$event => handlerFuncName($event, 'my custom data')" or @mousedown="mouseDownDataInYourComponent = true"
You need to remember only a few directives:
- v-for directive is for loops, iterates through your collection like: v-for="(value, key) in youObjectOrArray", so now you can use your value or key easily (I hear "meh, why value first?", well, you usually do value in yourArray)
- v-if, v-else-if and v-else for conditional rendering, your nice replacement of ternary operators in JSX. Use like v-if="userLoggedIn" (or simple v-show to display: none; of (!)mounted components, you will quickly find out how awesome this helper, no css or inline styles needed now!)
- v-model - your hero that saves you from writing methods that setState for each dynamic input. You now can have <input v-model="searchText" /> that is the same as <input :value="searchText" @input="updateSearchTextValue)" /> (can you guess what this example from docs does: <input v-model.number="age" type="number">?
- you can see or create a custom one, they usually start with v-* and adds some cool features.
To render some data you use mustaches: <h2>{{ variableName }}</h2>, no need those for just text: <h2>search</h2>.

That's basically it! Having this knowledge, let's define our template:

<template>
  <header class="main-header">
    <img src="../assets/logo.png" alt="logo" />
    <input placeholder="search" v-model="searchText" />
    <button @click="openModal">Write a post</button>
    <img v-if="user" :src="user.photo" alt="User avatar" />
    <button v-else>Login</button>
  </header>
</template>

No questions here, right? Maybe only where is this dynamic data comes from, like user or functions like goToNewPostPage?

Let's define data and logic

Now we can go to a script tag. We selected class-based sytax for easier transition from React and we have TypeScript support just for fun. Let's start:

<script lang="ts">
</script>

Now let's go to the body:

// think about this as import React from "react"
import { Component, Vue } from "vue-property-decorator";

// with this decorator we're saying to compile regular Vue component from our class
@Component
export default class DevToHeader extends Vue {
    user:User = null;
    searchText:string = ""; // two-way binding in v-model works with this guy

    openModal(event: Event) {
      this.$emit('openCreatePostModal', event);
    }
}

type User = IUser | null;

interface IUser {
  photo: string;
  name: string;
}

In this way, we defined data in our component and method that $emits data. Remember that @customEvent="handlerForIt"? Well, now a parent of our header can listen to the event @openCreatePostModal="handlerForIt" and the handler will receive event as an argument. And we can pass any data we want to our parent.

some vue-specific methods or data always start from `$` sign.

Q: Where is our componentDidMount?
Well, just define a mounted method:

  // ...
  async mounted() {
    this.user = await fetchUserData()
  }
  // ...

User updates -> component updates -> view updates. Easy.

Q: What about static getDerivedStateFromProps(props, state)?
Okay, let's pretend that we get username from parent and we want to change the path to the avatar depending on username. For this, we to change a bit:

import { Component, Vue, Prop } from "vue-property-decorator";

@Component
export default class DevToHeader extends Vue {
    @Prop({
      type: String, // your `prop-types` checks out of the box
      default: null // we don't really need that
    })
    username:string | null = null; // now for TypeScript
    // our photo src path that we will use as img :src
    photoSrcPath: string | null = null;
  // ...
}

All props are available as instance properties, the same way as our self-defined data. Let's add adding path now:

// import Watch decorator
import { Component, Vue, Prop, Watch } from "vue-property-decorator";

// ... or component class
    // watch for 'username' property
    @Watch('username', {
      immediate: true // call this function also on component mount
    })
    changePhotoPath(username:string | null) { // takes (newValue, oldValue)
      this.photoSrcPath = username ? `/user/${username}/data/avatar.png` : null;
    }
// ...

So we change our state based on property change, is it the most common case for getDerivedStateFromProps? And yes, you can watch for your "state" data propertes as well. Watchers are very powerful 💪.

But how can we handle it in a Vue way? Computed properties! Since we don't need to change any other data in our component, don't have complex logic and we don't need to make any async requests, it makes sense to have a simple property that will change based on username. And computed properties are the way to go, they are performant, they have cache and easy to write and use:

  // remove photoSrcPath data property
  // define computed property:
  get photoSrcPath():string {
    return `/user/${this.username}/data/avatar.png`
  }

Now our img tag:

  <img v-if="username" :src="photoSrcPath" alt="User avatar" />

Of course you can have any kind of stuff in computed, like I had once a bunch of filters for the same input collection:

// ...
    get filteredByA() {
      return this.collection.filter(filterByA).map(setFlags);
    }

    get filteredByB() {
      return this.collection.filter(filterByB)
    }

    get filteredByC() {
      return this.collection.filter(filterByC).map(setFlags);
    }
// ...

No need to store it in state, implement shouldComponentUpdate or stuff. And again, they're very performant.

Add our component

Let's go to the views/Home.vue and add our component there:

import { Component, Vue } from "vue-property-decorator";
import HelloWorld from "@/components/HelloWorld.vue"; // @ is an alias to /src
import DevToHeader from "@/components/DevToHeader.vue";

@Component({
  components: {
    HelloWorld,
    DevToHeader // becomes 'DevToHeader': DevToHeader
  }
})
export default class Home extends Vue {}

Now we pass into decorator some options, specifically components. In this way, we're saying to Vue compiler which components we're going to use in our template. Vue automatically changes PascalCase to kebab-case to use in templates (or you can name it yourself, like 'hello-w': HelloWorld). So inside our Home.vue template we can use our component:

  <div class="home">
    <dev-to-header
      username="Alex"
      @openCreatePostModal="$router.push('/newPost')"
    />
    <img alt="Vue logo" src="../assets/logo.png">
    <hello-w msg="Welcome to Your Vue.js + TypeScript App"/>
  </div>

We pass "Alex" as a username prop and attach a listener to our component. Our header didn't know, but there is no modal, we should just go to another page (yeah, we should rename this event now), so I wrote an inline function here. Remember inliners🔝? They're not very good from DX perspective, but for some simple stuff, to avoid boilerplate, why not? We're people after all...

So this inliner actually calls this.$router.push('/newPost'), so what's $router?

vue-router

Did you have an experience of your router setup being rewritten a couple of times because of React-Router upgrades? Look at this setup that almost didn't change with time:

Already see bundle split on page level thanks to dynamic import?

Vue.use(Router) adds a couple of global components for you, that you can use in templates as <router-view/> and <router-link to="/about">About</router-link>. And superproperties to your Vue instances: $route which contains your current route info, like params, query, metadata and $router which gives you methods to manipulate router programmatically. Good stuff, good stuff.

vuex

Thanks to Vue.js reactivity system, you don't need thunks, sagas and connect. You just define store, as in the example project, and use it as one more superproperty this.$store in your components. Async actions, mutations, modules, middleware - everything is just there. Need one more really awesome abstraction that can reduce your codebase - vuex-pathify looks pretty.

You are a weirdo and love JSX

JSX is supported, it's a babel abstraction and Vue uses the same render method approach as React.

React.createContext?

Yup, also there. You define provide property in parent component and inject: ['nameOfPropertyToInject'] in your any depth children component.

Just try it

There is no point to resist of trying new tools. I often don't understand people who don't like Vue even without really trying it. At the end of the day, this is the tool to improve your productivity, your users happiness. If it doesn't work for you, then leave it, but don't give up early. I had an issue with changing mind back from everything should be immutable, calling this.smth = ... made me feel like I'm doing something wrong or cheating. No, it's just because we used to write React code (just JS, yes 🙃). Can't not to mention that I also started to improve UX of any app by adding transitions, because they're very easy to set up and use in Vue.

Thanks for reading, see you on Twitter or maybe in live..?

* (I received questions about how to know when to put a component to `views` folder and when to `components`. Well, if your component is reused, say on different pages/views or other components than put it in `components` folder.

Forem: Alexander Vechy

CSS only list filtering, or abusing the platform

Self-inflicted problem (as many are)

Bringing solution to the problem that doesn’t exists; get two more problems

Solution

Show the articles matching the filter

Resetting the state

Sprinkles

Summary

Maximizing the benefits of Tailwind

There are two worlds

Becoming a cautious fan of Tailwind

TailwindCSS is not for building component libraries

The result

Creating API for components: flexbox layout

Start

Wrapping

Flow direction

Alignment

Spacing

End

Making your React component library meaningful in 2021

TypeScript

Accessibility

Developing React component library in 2021

Note on usage

Choosing the right tools for React component library in 2021

How to style in 2021?

How to write documentation in 2021

Accessibility

Now, where do we deploy it in 2021?

5 outcomes from building a Chrome extension with Svelte

What's Svelte?

How's experience?

You should go over Svelte Tutorial at least once

Initial setup

eslint + prettier + svelte = ❓

No TypeScript yet

Too late to be young

Small update on Redux usage

Folder structure

Event-driven reducers

It's all interconnected 🔝

Cover image reference: React Redux Tutorial for Beginners: Simply Explained

A guide to higher salary

You love your company and feel that you deserve to be paid more

Find motivation

Start listening

Start thinking about the product

Be a person to ask

Battling Imposter Syndrome By Understanding the Dunning Kruger Effect

Kaleb M ・ Apr 29 '19

Three Tips for Managing Impostor Syndrome

Ali Spittel for Ladybug Podcast ・ Aug 6 '19

Otherwise...

Building global store with React Hooks

Problem statement

Before Hooks

useStore

What's next?

Add Vue to your acknowledged stack

TL;DR

Let's start

(quicktip: Vetur is a Vue syntax helper for VS Code)

Quick intro to templates

Let's define data and logic

some vue-specific methods or data always start from $ sign.

Add our component

vue-router

vuex

You are a weirdo and love JSX

React.createContext?

Just try it

* (I received questions about how to know when to put a component to views folder and when to components. Well, if your component is reused, say on different pages/views or other components than put it in components folder.

** Yeah, I know about stuff like v-bind="$attrs" let me keep this article shorter? :)

Cover photo: https://blog.pusher.com/building-external-modules-vuejs/

`eslint` + `prettier` + `svelte` = ❓

`useStore`

some vue-specific methods or data always start from `$` sign.

* (I received questions about how to know when to put a component to `views` folder and when to `components`. Well, if your component is reused, say on different pages/views or other components than put it in `components` folder.

** Yeah, I know about stuff like `v-bind="$attrs"` let me keep this article shorter? :)