A typical use-case on web for maintaining React State is your URL's query parameters. It lets users refresh pages & share links without losing their spot in your app.
URL-as-state is especially useful on Next.js, since next/router will re-render your page with shallow navigation.
This gist lets you leverage the power of URL-as-state, while providing a fallback to React state for usage in React Native apps.
It's essentially a replacement for useState.
| -- Usage: _="install Draggable(dragHandle: .titlebar in me)" | |
| behavior Draggable(dragHandle) | |
| init | |
| if no dragHandle set the dragHandle to me | |
| end | |
| on pointerdown(clientX, clientY) from dragHandle | |
| halt the event | |
| trigger draggable:start -- hooks, e.g. for adding a drop shadow while dragging | |
| measure my x, y |
In computing, memoization or memoisation
is an optimization technique used primarily
to speed up computer programs by storing
the results of expensive function calls and
returning the cached result when the same
inputs occur again.
— wikipedia
// src/index.js
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
// Switch between them with comments
// import GraphQLProvider from "./Apollo"
We present a program analysis motivated by the need to solve some termination problems observed during the development of a parser for the new syntax introduced with the ReScript language. Learning from previous experience, it was decided to avoid parser generators, and go instead for a hand-crafted parser. In this way, the parser could be optimized for performance, be more maintainable, and most importantly give much more flexibility with error messages.
The new parser delivered on the promises, though a new issue appeared during live testing. The laptop would get hot once in a while, and only improve after re-starting the editor. Not all the time, but often enough to notice. The problem was an infinite loop in the parser, triggered by unexpected character combinations introduced while editing and never encountered in automated tests. It took a while to reproduce the issue and locate a mistake in the p
Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.
Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.
I'll preface this with three things. 1. I prefer schemes over Common Lisps, and I prefer Racket of the Schemes. 2. There is more to it than the points I raise here. 3. I assume you have no previous experience with Lisp, and don't have a preference for Schemes over Common Lisp. With all that out of the way... I would say Common Lisp/SBCL. Let me explain
Now as to why Common Lisp over Scheme
"Art prior" to React:
Martin Fowler: InversionOfControl (2005-Jun-26)
Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.
The litmus test:
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette.
Keep it simple, stupid. You ain't gonna need it.
