samsch

#!/bin/bash

name=$1

if [[ -n "$name" ]]; then
    if [[ $name =~ ^[a-z_]+$ ]]; then
        sudo -u postgres createdb $name
        sudo -u postgres createuser $name
        sudo -u postgres psql -c "alter user $name with encrypted password '$name';"
        sudo -u postgres psql -c "grant all privileges on database $name to $name;"

samsch

The effect on SEO related to React comes from doing client-side rendering only. So this isn't React specific, any client-side-only view will suffer from this. But yes, SEO explicitly suffers for non-Google search engines which don't run the JavaScript for a page. Basically, your page is effectively blank. Google does run JavaScript, but their algorithm is intentionally quite complex and takes into account many factors, some of which (like initial render performance) can be affected by using only client-side rendering.

In reality, most sites where SEO matters for the pages probably should not be rendered on the client, or at least not on the client only. The web is designed around servers generating html, and unless you have a strong reason not to, it's better to fall in with that paradigm by default.

So then, there are two ways React can still be valuable, even when rendering on the server. The simpler way is to just use React as a server side templating language. I've been doing this on a current project,

samsch

There is no such thing as stateless authentication

The big "make everything stateless" hype is just that: hype. Your server-side application code, should usually be stateless, because this makes your application more resilient to errors, easier to scale, and easier to reason about. But there are exceptions to even that, especially for stuff like video game servers.

Your services are almost always going to be stateful, and should be. If you have a database, files, or literally anything that affects the responses the server sends, then the service is not stateless.

So building "stateless" services is a lie. You shouldn't strive to make your services stateless, you should make sure you're putting your state in the correct place.

Where does my state go?

samsch

[FOR HIRE][REMOTE] I'm an expert in React architecture and ecosystem, and a skilled full stack developer.

Allow me to get on board with your project or team for feasibility consulting, technical evaluation, code review, or general development. You can also contact me to setup sessions for private one-on-one React and ecosystem support or mentoring.

I'm knowledgeable in most of the widely used tools in the React ecosystem, including: React, Webpack, Babel, Eslint, Redux, React Router, Material UI, Redux, Saga, Thunk, React Final Form, Node.js, Express (and standard middleware libs), Knex, Postgres, MySQL, and more.

My number one soft skill is quickly discovering both long and short-term solutions to problems (respectively for ideal situations and for quick workarounds).

You can contact me via email to sam@samsch.org or DM on Discord to samsch#1439.

samsch

Stop using JWTs!

TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.

If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)

A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/

The reason to avoid JWTs comes down to a couple different points:

• The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions

samsch

const ScrollHandler = React.memo(() => {
  return (
    <Route>
      {({ history }) => {
        history.listen((location, action) => {
          if (action !== 'POP') {
            window.scrollTo(0, 0);
          }
        });
        return null;

samsch

import React from 'react';

class Effect extends React.Component {
  componentDidMount() {
    this.previous = this.props.onRender();
  }
  componentDidUpdate(prevProps) {
    console.log('cdu');
    if (
      prevProps.cache &&

samsch

Addressing some concerns and questions about React Hooks

We don't need another type of component, classes work fine!

[or] Why do function components need this, we already have the functionality in classes? Won't that just be confusing which to use?

This is directly addressed in the React Conf talk and the intro page here: https://reactjs.org/docs/hooks-intro.html

Classes have several problems, one of the biggest being that this handling and binding is a very common source of mistakes for both new and experienced developers.

samsch

function renderContexts(render, contexts) {
  const [name, Consumer] = contexts[0];
  return (
    <Consumer>{
      value => {
        if (contexts.length === 1) {
          return render({ [name]: value });
        }
        return renderContexts(values => render({ ...values, [name]: value }), contexts.slice(1));
      }

samsch

First off, this is just a list of negatives. These libraries will also have advantages compared to each other which aren't listed here, and could make them actually be reasonable choices.

Specifically, latest Material UI is a "good" library, if it's not a problem for you that it's a little heavy.

In the current list, MUI is the only one I'd generally recommend.

Blueprintjs

• Doc examples don't include required and relevant imports.
• Doesn't obviously support separate imports for components.