samsch

My problems with Scarf-js

The @scarf/scarf package uses the postinstall package.json option to run a script that makes a request to [somewhere] with potentially sensitive data, and can be configured to do that with no (reasonably visible) user notice. As per almost any technology, the tech involved isn't inherently bad.

General principle

This is a fairly weak argument on it's own, but it's the "gut feeling" one that leads to others.

Libraries are expected to be installed with npm i, and to take no action besides what they require to be installed.

samsch

There are a couple ways to handle this. You could generate different bundles for each client, but if the bundle itself is what contains the generated layouts/data choices, then you would have to rebuild that bundle for each change, and for all clients for updates to the base code. I'm not going to say there couldn't be a case where that makes sense to do, but I can't really think of one. What would be more "normal" is to have your bundle build the layout based on a declarative data structure you can easily store in a database.

A really primitive form of this would be a simple conditional rendering:

// settings is coming from the DB
const Component = ({ settings }) => {
  if (settings.itemA) {
    return <ItemA />;
  } else {
    return <ItemB />;

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

import React from 'react';
import {
  BrowserRouter as Router,
  Link,
} from 'react-router-dom';
import Switch from './Switch';

const MyRoute = ({ name }) => {
  React.useEffect(() => {
    console.log('Mounted');

samsch

I created this because I was frusterated by having to change the integer values when the environments changed for my projects. A simple update of PHP 5.6 (I think it was PHP 5.6.16 to 5.6.17) changed the integer values, which are usually what is suggested to be used in parameters.yml or config.yml.

By using the constants, you don't have to worry about stupid stuff like that. (Since that's what they were designed for.)

samsch

Working with Postgres JSON datetimes

By default Laravel uses Y-m-d H:i:s for datetime parsing and formatting against the database. It gets this value as the connection default.

Postgres uses Y-m-d H:i:s as the datetime format default for all fields. Except that it does not follow this for datetimes that are serialized as JSON, where it follows ISO 8601 and formats as Y-m-d\TH:i:s.

Laravel is fortunately able to use a manually set datetime format, so after you hydrate a model with datetime from Postgres JSON with datetimes, you should call $modelInstance->setDateFormat('Y-m-d\TH:i:s'); so that datetimes are parsed correctly. Fortunately, this does not break writing to the db, which seems quite happy to accept ISO 8601 datetime strings.

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

[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

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 &&