Echo JS 0.11.0

Does anyone know of a similar component that is an isolated web component?  Or React?  would be nice to see some comparison examples.

My only concern here might be the size of the script(s) involved.  But it's very cool, and if the payload is under 20-30k probably worth it. :-)

Sigh: how many of these does *ANYONE* need?

Should this really be on this site?  I'm half tempted to delete the post.

That said:

Regarding Dockerization early... I'm not entirely sure I agree... while down time is bad, lifting/shifting the database to a bigger server isn't too hard... same goes for the website.

You can get to be incredibly huge on a single database server, and a single application server if the code is well written to support that model...  Stack Overflow grew vertically a *LOT* before they needed more than 2 servers.

Personally, I'd say Dockerize early for a more streamlined development CI/CD process.  Depending on the database and application chosen, closer to bare metal may be a wiser choice.  If you really want to invest in multiple DB servers up front determine what your needs are.  Is it absolute scaling, or is it read-redundancy?  These things should shape decisions.

Can't wait for the Private member bits to make it in.  Though still have to have it in SpiderMonkey and a few months beyond that.  Right now, I'm targeting ES2017 support for internal applications (babel for newer features), will be nice when ES2020 is the standard that I can ignore what came before.

Not really a rundown of how to document your code so much as a list of tooling options for creating documentation from your code.

Seems a bit convoluted... would be nice if this were isolated into a set of NPM modules, one for abstracting the baseline google library and another for the React UI/UX integration.

First, should probably use a ref when wiring the initialization controls.

Second, I'm not sure how the onSuccess actually gets wired or fired from the child component into the UI itself here...

Yet another static site generator...

I do think that the thunks library, and using async functions should have been included.  Saga and Observable libraries are heavy and generally take quite a bit of setup, where with thunks + actions you can often get the job done pretty easily, and have a simpler codebase.

I think the one case for Redux missed is when you need to share the same data/state across disparate components that may be in differing routes or different sections of a screen(overlaps with prop drilling).

For example, I have common subheaders in different screens on an app I am working on.  The routes are different, but that component is sharing state across the different routes and parent components.

I don't have any boilerplate or an article to show, but my approach is usually as follows.  These are regardless of the specific dbms, I've done it with MS-SQL and MySQL, I'd presume it should be an adaptable approach for Postres as well.

Have a directory for DB versions... this directory will then have a .js file for each version, it will export a default and optionally a rollback.

When the application first loads, it will run a pre-init db script that will first create an AppSettings key/value table, if it doesn't exist, where the key is nvarchar, and the value is json.  It will then check for a current version, setting it to 0, if there isn't a record.

The current version is compared against the directories, and if the current version is less than the directories indicate, it will get/set a *LOCK* record (mutex) in the database, then check again.  The *LOCK* will retry in a loop to set the mutex/lock record to its' own id, and after finished, delete that record.  After comparing again, it will run through each update script.

Each update script will be run, if no errors, then the version record will be updated to the current version.  If there is an error, and a rollback export exists, it will be run, and the application will log an output, and terminate.

After all updates have ran, and the lock record is cleared, the application will continue to start.  Optional: If it's a service, start the service, but return 503 responses until the database is updated.

This approach allows any number of deploys of the application/api to get the database to the current version, and the locking prevents more than one instance from trying to run updates.

It's worked out really well for me in applications I've built.  It's a bit of manual work for the setup, but after a few DB versions/releases tends to become more than worth it.  It also tends to be simpler than using some of the DB/version management tools.