DEV Community: anpos231

Company switching to Macs, should I switch my job?

anpos231 — Thu, 15 Aug 2019 20:02:43 +0000

Like in the title.
The company said they will be getting Mac laptops for everyone. Everyone will have to use them as it's not an option.

The main reason they give is that the IT support will have much less work to do (like Ubuntu desktops ever required much attention).
The second reason is that Macs are supposed to be faster than current desktops (just give us better desktops).

Up to this point I was hoping that people who want to stay on Linux will have that option. As you can tell I am not very enthusiastic with the switch, and I seriously started considering switching jobs.

#help?

React hooks & the closure hell 2

anpos231 — Sat, 29 Jun 2019 21:19:33 +0000

React hooks & the closure hell 2

This is a continuation of my last post (React hooks & the closure hell)

Just a quick tl;dr

Functional components require you to regenerate all your callbacks on each re-render because there is nowhere to store them (In old class based components you could just bind your functions as method and you were good to go).

Previous solutions required you to either specify dependencies so they could be passed to existing function, or to work with objects that would store current properties and values. I think these solutions were cumbersome, so I kept tinkering and created even better solution!

Meet `useCallbacks`

const useCallbacks = (reinit) => {
  const data = useRef({ callbacks: {}, handlers: {} })
  const callbacks = data.current.callbacks
  const handlers = data.current.handlers

  // Generate new callbacks
  reinit(callbacks)

  // Generate new handlers if necessary
  for (let callback in callbacks) {
    if (!handlers[callback]) {
      handlers[callback] = (...args) => callbacks[callback](...args)
    }
  }

  // Return existing handlers
  return handlers
}

Usage (Try here)

const App = () => {
  const [value, setValue] = useState(1);

  const handlers = useCallbacks(callbacks => {
    callbacks.handleClick = (event) => {
      setValue(value + 1)
    }
  })

  // Check console, the state has changed so the App function will re-run
  // but memoized ExpensiveComponent won't be called because the actual handling
  // function hasn't changed.
  console.log(value)

  return (
    <div className="app">
      <ExpensiveComponent onClick={handlers.handleClick} />
      <button onClick={handlers.handleClick}>
        I will not trigger expensive re-render
      </button>
    </div>
  );
};

And that's it!
You don't have to specify any dependencies or work with messy objects.
The callback is regenerated but the actual handling function is not, so your pure components or memoized components won't re-render unnecessarily.

Everything works as hooks intended!
Tell me what you think.

React hooks & the closure hell

anpos231 — Mon, 24 Jun 2019 14:59:36 +0000

React hooks & the closure hell

Since Facebook introduced functional components and hooks, event handlers become simple closures. Don't get me wrong, I like functional components, but there is a number of issues that niggle at me, and when I ask about them in the community, the most common answer is: "don't worry about premature optimizations".

But that is the problem for me, I grew up programming in C, and I frequently worry about the performance of my applications, even if others find it less significant.

The problem?

Since event handlers are closures we need to either re-create them on each render or whenever one of it's dependencies changes. This means components that only depend on the event handler (and possibly not on the handler's dependencies) will have to re-render too.

Consider this example code (Try here):

import React, { useState, useCallback, memo } from "react";
import ReactDOM from "react-dom";

import "./styles.css";

let times = 0

const ExpensiveComponent = memo(({ onClick }) => (
  <p onClick={onClick}>I am expensive form component: {times++}</p>
))

const App = () => {
  const [value, setValue] = useState(1);

  const handleClick = useCallback(
    () => {
      setValue(value + 1)
    },
    [value],
  );

  return (
    <div className="app">
      <ExpensiveComponent onClick={handleClick} />
      <button onClick={handleClick}>
        I will trigger expensive re-render
      </button>
    </div>
  );
};

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

In the previous example, clicking on the button will cause ExpensiveComponent to re-render. In case of class based components it would be unnecessary.

Solution?

The experimental tinkerer I am I tried to find the solution to this problem, solution where we can use functional components, but don't have to create a new callback every time we create a new value.

So I created useBetterCallback(fn, deps). The signature for this function/hook is identical to useCallback(fn, deps). The difference is that it will always return the same identical handler no matter what.

Some of you might think: 'So how do I access fresh state values?'. useBetterCallback will call your handler with one additional argument, and that argument is an array with all dependencies your callback depends on. So instead of recreating the callback we pass new values to existing one.

Here is the source code for the useBetterCallback hook.

const useBetterCallback = (callback, values) => {
  const self = useRef({
    values: values,
    handler: (...args) => {
      return callback(...args, self.current.values)
    }
  });
  self.current.values = values
  return self.current.handler
}

And here is an example of the useBetterCallback in action (Try here):

import React, { useState, useRef, memo } from "react";
import ReactDOM from "react-dom";

import "./styles.css";

const useBetterCallback = (callback, values) => {
  const self = useRef({
    values: values,
    handler: (...args) => {
      return callback(...args, self.current.values)
    }
  });
  self.current.values = values
  return self.current.handler
}

let times = 0

const ExpensiveComponent = memo(({ onClick }) => (
  <p onClick={onClick}>I am expensive form component: {times++}</p>
))

const App = () => {
  const [value, setValue] = useState(1);

  const handleClick = useBetterCallback((event, [ value, setValue ]) => {
    setValue( value + 1 )
  }, [value, setValue])

  console.log("Value: " + value)

  return (
    <div className="app">
      <ExpensiveComponent onClick={handleClick} />
      <button onClick={handleClick}>
        I will not trigger expensive re-render
      </button>
    </div>
  );
};

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

Review?

What do you think?

Weird browser behaviour?

anpos231 — Fri, 07 Jun 2019 01:41:45 +0000

So I was playing with a search box, I wanted it to show/hide based on the content and whether it was focused or not, but I did not want to use width property for animation. Instead I went for transform: translate and tried to hide it behind the button when not needed.

I've noticed a weird behaviour though. When I hover over the element the box seems to render properly, but when I try to tab into it, the button starts to 'jump' and if you try clicking somewhere else on the page while the animation is running, the whole thing will just freeze, with the button staying in incorrect place.

Here is the code pen: https://codepen.io/anon/pen/vwqZxR

Performant infinite lists and accessibility.

anpos231 — Fri, 07 Jun 2019 00:51:24 +0000

I read this article on medium:
https://medium.com/walmartlabs/infinite-scrolling-the-right-way-11b098a08815

The author says, that to keeps things performant, we can reuse existing <li> elements, instead of adding new <li> to <ul>. And to create an immersion of scrolling we can use padding on <ul>.

One question immediately came to my mind: since screen readers announce the size of the list, based on the actual number of <li> inside <ul>, screen reader users will be unable to find out how big that list actually is.

Non-screen reader users will fill the immersion, but screen reader users wont.

DEV Community: anpos231

Company switching to Macs, should I switch my job?

React hooks & the closure hell 2

React hooks & the closure hell 2

Just a quick tl;dr

Meet useCallbacks

Usage (Try here)

React hooks & the closure hell

React hooks & the closure hell

The problem?

Solution?

Review?

Weird browser behaviour?

Performant infinite lists and accessibility.

Meet `useCallbacks`