samsch

Why React Data Fetching is Hard (right now)

Context

Recently Dan Abramov has been linking drafts of a new documentation page for useEffect, which has kicked off discussion about where you are "supposed" to do data fetching in a "React app". Some of that conversation is happening on Twitter such as here: https://twitter.com/dan_abramov/status/1532540685710147589

Within the draft and repeated on Twitter, there is a recommendation that for data fetching you should use third party libraries as either tools like React Query or useSWR or via frameworks such as Next and Remix which include integrated data fetching solutions. Writing your own data fetching using useEffect is suggested to be only a fallback in case you can't do those things, and not really a preferred recommendation.

This idea is hitting backlash, with a basic detracting idea that boils down to: React is a client side framework, how can it not include as a feature an important and common requirement like data loading.

samsch

Common issues

Multiple origins

By default, the cookies express-session sets will not work if your server's url isn't the same origin as your front end page where you are making requests from. For example, if you are using Create React App's server on localhost:3000, and your server is running at localhost:8000, cookies won't be saved without extra configuration for CORS.

If you can avoid multiple origins, I recommend doing that. A single origin avoids CORS configuration which tends to be troublesome. Most front end build tools (including Create React App) have options to proxy requests to your backend server. Even better are tools which build your front end to files that can be directly served by your backend (such as using Parcel's watch command).

The CORS configuration will include:

• Setting SameSite on your cookie options to none.

samsch

knex
  .select([
    'users.*',
    knex.raw('json_agg("posts") as posts')
  ])
  .from('users')
  .leftJoin(function () {
    this.select(['posts.*', knex.raw('json_agg("comments") as comments')])
      .from('posts')
      .leftJoin('comments', { 'posts.id': 'comments.post' })

samsch

When should I use relational vs NoSQL databases?

What is the task you need to accomplish?

Frequently this question is asked as a "what should I use for a web app" question with no real details for what kind of data is being stored. As it turns out, that's ok! We actually have a type of database which directly fits "general purpose", by being fully robust and flexible. These are the relational databases, which are designed around the SQL standard.

Because "general purpose" covers most tasks really well when it comes to databases (something that's not nearly as true in other areas of technology), you can just grab PostgreSQL or MySQL and use that for all data storage purposes, and likely have no issues for the full lifetime of the project.

When general purpose is not enough

samsch

All Data is Relational

Think of the least relational data you can come up with.

That data, and each item in it, has explicit and implicit relationships.

If it's a list of items, then the items are explicitly related to each other by nature of being in the same list. A list is a type of relationship.

If you have an app that stores random items which are each completely unrelated to each other... they are all related to the app.

samsch

Some links

• https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
• https://movingfast.io/articles/environment-variables-considered-harmful/
  • HN: first comment offers a rebuttal, but the first child comment of that explains what's wrong with that rebuttal: https://news.ycombinator.com/item?id=8826024
• Example where the leak wasn't a security issue in the specific case, but could very easily have been (leaked encryption key): https://exceptionshub.com/php-laravel-environment-variables-leaking-between-applications-when-they-call-each-other-through-guzzlehttp.html

A simple alternative is to put your sensitive (or all) config in a .json file that is gitignored. This also has the advantage of being easily generated using tools which can retrieve the sensitive data from a secure store (e.g., via ssh using user ssh key). With Node.js, .json files can be directly require()d, which is an additional convenience.

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

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

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.