NOTE: You can *NOT* rely on this method to complete before the tab/window closes. It may or may not work depending on latency to the server, or the time it takes to fulfill the request etc.
Make other efforts using localstorage and a worker, if you want to avoid this failing to finish.
Decent example of leveraging event bubbling for form validation over specific input listeners. Would probably listen at the specific form level though, rather than the document level as a whole... but nice to see.
Here's the real issue, that isn't covered...
const MyButton = React.memo(({onClick, text}) => (
<button onClick={onClick}>text</button>
));
const Parent = () => {
const handleClick = (event) => {...};
return <MyButton
onClick={handleClick}
text="click me"
/>;
}
Every render of the Parent, will re-render MyButton... why, because the handleClick method is re-created every time and won't match.
This is why you want an event handler outside your component context in a state machine that has its own context higher in the stack. Redux does this well, but there are other options.
I'm not sure we need to go down the path of polymorphism by declaration in JS, let alone dealing with the fallout that comes with it. The inheritance model in JS has some real inefficiencies that are amplified by multiple layers of inheritance already and growing them with multiple signatures for methods won't do good at all. Especially without a type system, and there's already TypeScript for that, and even then it can only end badly as then you'll need runtime type checking that will fail in practice.
You're far better off embracing more functional or procedural approaches to software constructs in JS and leveraging the Class sugar when you need to encapsulate state with methodology and pass that around as a contextual pairing, and avoiding them everywhere else.
If you really want that kind of construct, I'd suggest working with a language that has the features you want targeting webassembly as the output. Not saying it's a good idea in many cases, but better than trying to shoehorn such a mess into JS.
Minor issue, having your event handlers (lambda functions) declared *in* your component context, then passing to "pure" components will trigger a re-evaluation cycle as the functions themselves don't match the prior instance.
I usually just stow the original initialization promise, and return that on future requests...
let _instance = null;
export default async function getResource(opts) {
if (_instance) return instance;
_instance = intializeInstance(otps).then(i => (
_instance = i
));
return _instance;
}
This will stow the promise, returning it initially, then when the concrete instance is there, will start returning that.
Here's the real issue, that isn't covered... const MyButton = React.memo(({onClick, text}) => ( <button onClick={onClick}>text</button> )); const Parent = () => { const handleClick = (event) => {...}; return <MyButton onClick={handleClick} text="click me" />; } Every render of the Parent, will re-render MyButton... why, because the handleClick method is re-created every time and won't match. This is why you want an event handler outside your component context in a state machine that has its own context higher in the stack. Redux does this well, but there are other options.Missing named exports. // index.js import foo from './foo'; import bar from './bar'; export {foo, bar};I usually just stow the original initialization promise, and return that on future requests... let _instance = null; export default async function getResource(opts) { if (_instance) return instance; _instance = intializeInstance(otps).then(i => ( _instance = i )); return _instance; } This will stow the promise, returning it initially, then when the concrete instance is there, will start returning that.