Polyfill dynamic import() in all ES Modules-supporting browsers.
Drop this polyfill into your page: https://github.com/GoogleChromeLabs/dynamic-import-polyfill
... then add the Babel transform:
import dynamicImportPolyfill from 'dynamic-import-polyfill';
Set up a docker-compose.yaml file (file content at the bottom of this page).
Also create a data/mysql folder in your project.
In order to set up a volume for MySQL in Docker Toolbox, we will need a VirtualBox Shared Folder, just like mentioned in Fixing Volumes in Docker Toolbox.
VirtualBox by default has a c/Users Shared Folder that we can use for this (as long as your project is within C:\Users. Verify that this shared folder is set up properly:
Add a new volume to the mydatabase service in the docker-compose.yaml for the database files. Because we are using docker-toolbox and VirtualBox, we need an absolute path, starting with //c/:
volumes:
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
| function execute(action, callback) { | |
| // create real promise, because execute method does not return the real one | |
| // (missing documentation what actually returns) | |
| const promise = new Promise((resolve, reject) => { | |
| grecaptcha.ready(() => | |
| grecaptcha.execute(key, { action }).then(token => { | |
| resolve(token); | |
| }, | |
| reject) | |
| ); |
| import * as ReactDOM from 'react-dom'; | |
| import { List } from '../components'; | |
| ReactDOM.render( | |
| <List | |
| items={[1, 2, 3]} | |
| renderItem={item => <li key={item}>{item.toPrecision(3)}</li>} | |
| wrapper={({ children }) => <ul>{children}</ul>} | |
| />, |
| // please check https://docs.netlify.com/configure-builds/environment-variables/#declare-variables for most up to date info | |
| // this was created before those docs existed | |
| process.env = { | |
| /** | |
| * | |
| * AUTOMATICALLY SET BY NETLIFY. IMMUTABLE! | |
| * docs: https://www.netlify.com/docs/continuous-deployment/#environment-variables | |
| * | |
| */ |
| // This is a minimal UA sniffer, that only cares about the rendering/JS engine | |
| // name and version, which should be enough to do feature discrimination and | |
| // differential code loading. | |
| // | |
| // This is distinct from things like https://www.npmjs.com/package/ua-parser-js | |
| // which distinguish between different branded browsers that use the same rendering | |
| // engine. That sort of distinction is maybe useful for analytics purposes, but | |
| // for differential code loading it is overcomplicated. | |
| // | |
| // This is meant to demonstrate that UA sniffing is not really that hard if you're |
| import { ApolloServer, gql } from 'apollo-server-micro'; | |
| const typeDefs = gql` | |
| type Query { | |
| sayHello: String | |
| } | |
| `; | |
| const resolvers = { | |
| Query: { |
| declare namespace AWS { | |
| namespace Lambda { | |
| /** | |
| * @see https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html | |
| */ | |
| type AWS_LAMBDA_JS_RUNTIME = 'nodejs10.x' | 'nodejs8.10'; | |
| } | |
| } |