import path from 'path'; | |
import { fileURLToPath } from 'url'; | |
import comments from '@eslint-community/eslint-plugin-eslint-comments/configs'; | |
import { FlatCompat } from '@eslint/eslintrc'; | |
import js from '@eslint/js'; | |
import nextPlugin from '@next/eslint-plugin-next'; | |
import eslintConfigPrettier from 'eslint-config-prettier'; | |
import hooksPlugin from 'eslint-plugin-react-hooks'; | |
import reactRecommended from 'eslint-plugin-react/configs/recommended.js'; |
/** | |
/DOBPicker.tsx | |
**/ | |
'use client'; | |
import * as React from 'react'; | |
import { format, subYears } from 'date-fns'; | |
import { cn } from '@/lib/utils'; | |
import { Button } from '@/components/ui/button'; |
Made this example to show how to use Next.js router for a 100% SPA (no JS server) app.
You use Next.js router like normally, but don't define getStaticProps
and such. Instead you do client-only fetching with swr
, react-query
, or similar methods.
You can generate HTML fallback for the page if there's something meaningful to show before you "know" the params. (Remember, HTML is static, so it can't respond to dynamic query. But it can be different per route.)
Don't like Next? Here's how to do the same in Gatsby.
There are lots of cases that you can improve. The examples use nullable reference types, but only the WhenNotNull
example requires it.
Consider adopting the new property pattern, wherever you use IsNullOrEmpty
.
string? hello = "hello world";
// This file was initially generated by Windows Terminal 0.11.1191.0 | |
// It should still be usable in newer versions, but newer versions might have additional | |
// settings, help text, or changes that you will not see unless you clear this file | |
// and let us generate a new one for you. | |
// To view the default settings, hold "alt" while clicking on the "Settings" button. | |
// For documentation on these settings, see: https://aka.ms/terminal-documentation | |
{ | |
"$schema": "https://aka.ms/terminal-profiles-schema", |
import React, { memo, useCallback } from 'react'; | |
import ChildComponent from './wherever/ChildComponent.js'; | |
const updateChild = (props, childId, changes) => { | |
props.onUpdate({ | |
type: 'childChanged', | |
childId: childId, | |
changes: changes, | |
}); | |
}; |
import { useReducer } from 'react' | |
export function updateName(name: string) { | |
return <const>{ | |
type: 'UPDATE_NAME', | |
name | |
} | |
} | |
export function addPoints(points: number) { |
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
This focuses on generating the certificates for loading local virtual hosts hosted on your computer, for development only.
Do not use self-signed certificates in production ! For online certificates, use Let's Encrypt instead (tutorial).