Generally, if you're passing properties from above to components below more than a layer or two, you're better off using Context and/or Redux (more advanced context).
I tend to find it's worth getting used to Redux's flow for *most* applications. There are alternatives (like MobX) but Redux works REALLY well in most applications. There are some configuration utilities that are Redux with enhanced configurations in the box as well. In the end, the pattern is a bit harder to get used to, but allows for feature scaling without linear growth of complexity.
GraphQL or Apollo are also good and can work well when the backend supports it especially on larger applications or development environments.
For small apps, you can go a long way with contexts and custom action hooks, but I'm inclined to just jump to Redux pretty early on.
while there's still need for optimizations (reduced deno runtime for merged executable) as well as an improved binary module story, it's a pretty big feature to get in the box.
Been following Deno with great interest since it was announced, and the goodness keeps on coming.
Would suggest taking a look at Steve Souders' books[1] on website performance. While they're a bit old at this point, there's a lot to gain from them. As always, if you're really concerned about performance, write test cases for your assertions, as you may be surprised that your "optimization" does more harm than good.
As always, premature optimization is often a waste of time... optimize when you experience issues as writing more obtuse or difficult to understand code/structures will often work against you if you aren't writing apps for 100m+ user sites.
When in doubt, test.
[1] https://www.amazon.com/Steve-Souders/e/B001I9TVJS
You aren't doing meaningful checks or adding additional TS context, so why even bother with adding a tsconfig? Most IDEs will apply those checks with the jsdoc alone and it isn't actually checked at runtime.
Two niggles...
First: The following is TypeScript, and not the current version. While I've actually converted a lot of the projects I'm working on to TS, prefer most training examples in plain JS, also assigning the right type to the event would probably correct the any type casting.
const file = (event.srcElement as any).files[0];
...
const base64Str = btoa(reader.result as string);
Second: There's no mention of getting the correct mimetype and/or extension from the File interface.
Nice... put in a feature request for yaml/toml support... Been using yaml myself for this kind of thing for a few years now. A closer to the box linter would be nice.
Two niggles... First: The following is TypeScript, and not the current version. While I've actually converted a lot of the projects I'm working on to TS, prefer most training examples in plain JS, also assigning the right type to the event would probably correct the any type casting. const file = (event.srcElement as any).files[0]; ... const base64Str = btoa(reader.result as string); Second: There's no mention of getting the correct mimetype and/or extension from the File interface.