DEV Community: Adam Genshaft

The path to seniority

Adam Genshaft — Sun, 02 Apr 2023 20:37:37 +0000

Dream about one day becoming the CTO? Want more responsibility but are stuck in developing other people’s bugs into features? The path will surprise you.

For many years I’ve thought I’ma great developer since I get the technical things far and quickly. I thought that a developer is a mean code machine that mostly developer features.

Well, you probably already know that this attitude will take you so far.

The truth is that what I’ve described is no more then a code monkey, and that’s what I was for years.

My attitude started shifting after listening to Jocko Willink.

I realized that responsibility comes with great power, the power to influence others by communicative on an exceptional level.

Why do you think the CTO is trusted with the entire company? Since he’s the best coding monkey? Of course not. Being a good level on the company’s tech stack is a trivial thing after enough years of development. What separates the CTO is he’s identity as a part of the company, and his big picture perspective.

Not identifying as the company will make you look at your own good as if it’s separated from the organization, obviously if you’re the CTO it’s not.

The CTO is a critical part of the company, like a part of the brain. Imagine a part of your brain thinking it’s its own entity. Depending on how it happens, we’ll call it cancer or dementia.

Each part of your brain needs to work in the most effective way with the rest of you. Sane guess for the c level executive, Ave for every other role got that manager. If you’re not a post of the company, what is it that you do here? A salary? Bring…

I take part in the ongoing internet revolution, I’m a deliverer of technology, I do it using my work where we give a unique value to our customers.

What attitude you think will take you further?

If you’ve read so far let me tell you a secret, you already are the CTO of you’re task. Now that you know who you are, tell me, how good of a CTO are you?

A surprising thing happened when worked as a backend (old-time frontend)

Adam Genshaft — Sat, 09 Jan 2021 19:19:22 +0000

Just sharing with you guys...

I've been a frontend for the past 7 years or so. During that time I did a lot of so-called "full-stack" development where I do everything from the query of the DB to the front end CSS.

Recently, I've started working on a pure backend role. The most surprising thing that happened to me what I opened the browser to debug my work. I realized I don't need the browser! 🤯

A real internal paradigm shift...

Making autocomplete with react 🤯 common mistakes and their solutions

Adam Genshaft — Fri, 11 Sep 2020 22:34:56 +0000

Let's make an autocomplete with react and a promise-based HTTP client. Just a bit less trivial then it seems.

The examples below will show you the common mistakes, and how to write an autocomplete react component using a battle-tested pattern.

The problem

When first writing an autocomplete with react the most trivial mistake would be to make a request for each input change event, and use the responses as they arrive.

The code will look something like this:

import React, { Fragment, useState } from "react";
import { api } from "./api";

export const AutocompleteTrivialMistake: React.FC = () => {
  const [apiResult, setApiResult] = useState('');
  const handleChange = e => {
    api(e.target.value)
      .then((result)=>{
        setApiResult(result);
      });
  };

  return (
    <div>
      <h3>AutocompleteTrivialMistake</h3>
      <input onChange={handleChange} />
      <p>
        Search result: {apiResult}
      </p>
    </div>
    );
};

Note - at the bottom of the page there's a stackblitz with all of the examples shown here.

And the thing is that when you use it during development it looks like this:

The bug that will happen when the client uses it will look something like this:

To put it into words:

Expected - when deleting all the characters fast you should have the latest response coming from the latest request (an empty string).
Actual - when deleting all the characters fast you see the latest response coming from an older request (non empty string).

This bug is tricky because it will often work fine during development but it will cause bugs on production.

This happens because older requests are not canceled as newer requests are sent. This brings us to this bug where an old request will return after a new request. Meaning that the latest response we get is not representing the latest search string we typed. Resulting in 🤯

🤯

If you see this bug somewhere, remember that an easy way to reproduce this bug is by deleting characters fast. That's because when you reduce the number of characters the search becomes lighter, which results in a faster response, as you delete more characters.

So how can we solve it?

A trivial solution, but not yet bulletproof

The first and most obvious thing that we need to do is to cancel old requests when newer requests are made.

import React, { Fragment, useState } from "react";
import { api } from "./api";

let promise;

export const AutocompleteTrivialSolution: React.FC = () => {
  const [apiResult, setApiResult] = useState("");
  const handleChange = e => {
    promise = api(e.target.value);
    const localPromise = promise;
    promise.then(result => {
      // Only send use the response of the latest request
      if(promise === localPromise){
        setApiResult(result);
      }
    });
  };

  return (
    <div>
      <h3>AutocompleteTrivialSolution</h3>
      <input onChange={handleChange} />
      <p>API search result for: {apiResult}</p>
    </div>
  );
};

This will actually work, but just as long as the component is used in just a single place. Having the component in multiple places will result that all instances of the component will use the same local variable. It's a bad practice, and even tho it is less likely to create bugs, it still has an opening for unexpected behaviors.

The complete approach

At this stage, it should be clear that we need to create a local canceling mechanism for each component instance. We can accomplish it by creating a class that will have a new instance created for each component instance that is using it. Each instance will be responsible to cancel only requests made by that component. Let's dive into it.

import React, { Fragment, useState, useEffect } from "react";
import { api } from "./api";

export class Api {
  promise;
  async request(text) {
    this.promise = api(text);
    const localPromise = this.promise;
    const result = await this.promise;

    if (this.promise === localPromise) {
      return result;
    }
  }
}

export const AutocompleteCompleteSolution: React.FC = () => {
  const [apiResult, setApiResult] = useState("");
  const [apiClient, setApiClient] = useState();

  useEffect(() => {
    const client = new Api();
    setApiClient(client);
  }, []);

  const handleChange = async (e) => {
    if (!apiClient) {
      return;
    }
    const result = await apiClient.request(e.target.value);
    setApiResult(result);
  };

  return (
    <div>
      <h3>AutocompleteCompleteSolution</h3>
      <input onChange={handleChange} />
      <p>API search result for: {apiResult}</p>
    </div>
  );
};

Thanks for reading!

Hope you liked it, please let me know what you think.

Yours,
Adam.

NGRX | Use effects and router-store to isolate route related side 🧙🏼‍♂️ effects

Adam Genshaft — Tue, 05 May 2020 21:52:41 +0000

One of the major advantages of ngrx is that we can isolate side effects from the components.

When we need to have router related data on the component we'll usually use the ActivatedRoute service from the component itself. For example, we can get the id from a route using this technique:

export class MyComponent {
  id: string;
  id$ = this.activatedRoute.params.pipe(
    map(params => params.id),
    tap(id => this.id = id),
  );
}

Let's isolate this using @ngrx/effects. The first goal is to get the route param from the URL.

How not to do it

We might be tempted to try using the ActivatedRoute service on the effects, but it's useless. It's only accessible on the "associated with a component loaded in an outlet", quoted from https://angular.io/api/router/ActivatedRoute.

Another thing we might think of is to use the Router service. But again we won't have the url parameter accessible in a clear, easy to use way.

What we can do, is to use selectRouteParam state selector from @ngrx/router-store.

Let's dive into the example. (stackblitz link at the bottom of the article)

How it's done right

Setting up the effect:

  setCurrentCourse$ = createEffect(() => this.store$.pipe(
    select(selectRouteParam('id')))
      .pipe(
        map((id: string) => setIds({id})), // dispatch a new action to set the selected id
      ),
    {dispatch: true},
  );

Kudos for @timdeschryver for the simplified version 🤘🏼

Then our component can be as simple as:

import { Store, select } from '@ngrx/store';
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `{{selectedId$ | async | json}}`,
})
export class HomeComponent {
  selectedId$ = this.store.pipe(select((state: any) => state.featureName.selectedId));
  constructor(
    private store: Store,
  ) { }
}

The takeaways

That a basic example showing just how to get a param. The real power comes when we need to use that param and fetch some data with it. Then we'll have an effect where we'll use the mergeMap operator to fetch the data using this id from the URL. On the component, we'll just subscribe to the fetched data, and that's it.

If you liked it, please show me some love here or on my twitter @AdamGenshaft.