Skip to content

Instantly share code, notes, and snippets.

View samsch's full-sized avatar

Lumina Scheiderich samsch

View GitHub Profile
samsch / .md
Created June 4, 2022 00:08
Why React Data Fetching is Hard (right now)

Why React Data Fetching is Hard (right now)


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:

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 / .md
Created January 21, 2021 14:23
Express-session isn't saving cookies, or cookie seems to be ignored?

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 / js-query.js
Last active September 23, 2021 14:44
Nested Knex query
knex.raw('json_agg("posts") as posts')
.leftJoin(function () {['posts.*', knex.raw('json_agg("comments") as comments')])
.leftJoin('comments', { '': '' })
samsch /
Created September 13, 2020 19:33
When should I use relational vs NoSQL databases?

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 /
Created September 13, 2020 18:42
All Data is Relational

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 / .md
Created July 14, 2020 17:25
Don't put sensitive data in environment variables (including .env files)

Some links

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 / .md
Last active July 2, 2020 13:22
Issues with Scarf-js approach

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 / .md
Created May 6, 2020 23:01
Discord answer about how to do dynamic layouts or rendering

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 / Example.jsx
Created February 13, 2020 19:58
React Router Switch re-implementation
import React from 'react';
import {
BrowserRouter as Router,
} from 'react-router-dom';
import Switch from './Switch';
const MyRoute = ({ name }) => {
React.useEffect(() => {
samsch / .md
Last active October 11, 2019 15:48
Working with Postgres JSON datetimes in Laravel

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.