Echo JS 0.11.0

Replication is *NOT* a backup strategy...

Data corruption attacks will corrupt your replica nodes.

NOTE: If you're using a file system capable of stapshots, then you can use replication + snapshots for redundancy + scale, but you need to snapshot on more than just one node.

I really don't care for these types of articles, because they're usually written poorly and the questions themselves have many, many holes in them. I hit the filter, senior, practical..

First question uses stringify to compare two object... Unfortunately this does not work, because there is no guarantee of property order in serialization... Use json-stringify-safe[1]

#8 Does it make sense to add directive ‘use strict’ in modern scripts?  No... if you are writing ESM, it's not just that babel adds the "use strict" it's that strict is implied and Babel adds it for standards compatibility.  It's not needed, even if using modules directly in the browser.

#10 is really muddy and not better in terms of being well understood.

#13 is not something someone should be expected to know out of hand... beyond this, the trend is towards simpler wrappers such as parcel that handle a lot of this for you.

#15 incomplete, assumes lodash, may as well assume jquery if doing that.  Better to ask about how one would handle this, than specific examples. Should probably check against the src to see if it's already the appropriate image src.  the TODO comment has no functionality to enforce.

#18 setting the height doesn't change the exposed object's height (getter preffered).

That's as far as I'm going... 


1. https://www.npmjs.com/package/json-stringify-safe

Interesting, but just looking at the dev dependencies, can only guess that the output, if you bring it into a project that already has these dependencies will be bloated.

Would suggest just posting the esm modules to npm, and letting the downstream build the appropriate dependencies.  Stick to ES2017 compatible JS + ESM + JSX.

This article is *really* muddying a few conceptual things... you have your data, renderer and event handlers together with a class that really doesn't need to be a class.  Even if you don't want to put yourself into MVC, there are lots of other patterns that are appropriate for user driven interfaces with events (personally, I like redux).

It's pretty bad advice and doesn't even demonstrate the concepts it's trying to clearly.

Using an abstraction component below to asynchronously load areas of the application with particularly heavy references... like sections that use charts or xlsx to keep initial dependency size smaller.  Loading is just an svg+css spinner as a placeholder.

    import React, { Suspense } from 'react';
    import Loading from './app/Loading';

    // wrap a component into a lazy loader - for use with components below
    export default function loadComponent(importStatement) {
      const Component = React.lazy(importStatement);
      return (...props) => (
        <Suspense fallback={<Loading />}>
          <Component {...props} />
        </Suspense>
      );
    }

It's generally wrapping my feature component export(s) like...

    // feature/foo/index.js
    import load from '../load-component-import';
    export default load(() => import('./FooComponent'));

And the main feature exports are referenced in the Router.

Main smaller areas aren't wrapped like this.. but where it gets big on certain dependencies, it helps keep the main bundle at least not crazy... still big with react + material-ui baseline.

Not to be critical, but in general, if this is the type of templating being done, why not just use express, or similar to render server-side?

I don't think it's particularly hard... the issue is, it depends on what you expect from front end testing.

One of the best things about React + Redux, is if done properly, you can cover a *LOT* with unit tests alone on your action creators (dispatch) and the reducer(s).

On the latest project I'm working with... all components are functional and using hooks.  All event handlers for components are using bound action methods from the action creators.

This means, all actions can be tested via call/injection alone... the API and getState/dispatch passed into the event handlers.

All state changes through reducer tests... in the end, the components are pretty straight forward (material-ui) and reliable.  That part is more of a pain to actually test, but less impactful on logical workflows.

Kind of wish the razor-like engines (such as vash and bliss) had gained more traction... I really do like the syntax.

The article itself is really shallow and doesn't even cover what its' own summary mentions.

Nice demo.. that said, having a UI that displays the JS that is actually being used, without having to dig into the dev tools would be a huge improvement. Without it, especially if one uses a mobile device... in the abstract, without code samples, this demo is nearly useless.

I disagree hugely on momentjs being the best option for date functionality... date-fns and luxon are both much better options... momentjs is a massive dependency and *really* big.  Luxon was made by the momentjs team with the benefits of hindsight.  date-fns is more than likely more than enough and much lighter.