Echo JS 0.11.0

Here's how I use it...

https://gist.github.com/tracker1/f0b91b0bc07fe67d08ef2d6119707a2d

I guess I should expand on my initial reaction...

1. this takes something fast in JS and makes it slow... JSON stringify/parse functionality is very fast in JS generally speaking.  Adding this overhead makes it slow, for very little gain.

2. it's using decorators and not really documenting if it's TS, legacy or the current stage-2 decorators proposal.  The fact that the repo seems to indicate typescript leads me to believe it's TS based.  If this library is TS meant to work with TS, then why not just rely on TS signatures?

3. given the additional overhead vs. just using TS types for code comparability, it's dubious if this is any faster, better or slower for validation vs Joi and any number of existing validation frameworks.

4. the syntax is really noisy.  It seems like it's inspired by the ASP .Net Model validation patterns in some ways.

About the only place I might consider this would be within the context of a node based API service, and going back to the third issue, I'm unconvinced this is any better than any number of input validation tools already in existence, or that it's any easier to adapt in that context.  I would suggest adding some metrics/testing for seige on an API with various validation tooling including this one in place, including valid and invalid cases one and more layers deep into an object structure.

https://github.com/pichillilorenzo/jackson-js/issues/1

Babel, or typescript yes... decorators have been in limbo for 5+ years now, the current proposal has been developing for about 2 years, which is different than legacy decorators and will probably be several more years before this shakes out.

https://github.com/tc39/proposal-decorators

Yuck.

Looks nice.  Mostly using Joi these days (in koa, separate from hapi)

You may also want to consider the useMediaQuery or useViewportSpy hook from beautiful-react-hooks[1], since it's probably closer to what you may actually be trying to accomplish.

1. https://github.com/beautifulinteractions/beautiful-react-hooks

Should probably include examples of useContext and useReducer to round things out, but nice intro.

I would suggest if you are using a Component based toolkit that you use a UI/Component framework that does it's styling in a sane way (material-ui) over using a CSS centered framework.  This is especially for SPA and similar.

While this isn't the case for TFA, seems to be centered around server-oriented content, I'm just not a fan of CSS centered vs component centered frameworks if you're doing client-side development.  The disconnect becomes pretty big in practice.

Just my $.02 ... a notable exception might be if you're in a larger environment that has separate designer oriented resources and you are receiving most markup and styling from those resources.  Even thin, it's often better to turn your markup into component oriented logic.

While I prefer to just use fetch-api, for those that like the extras that axios gives, this module is roughly 1/5 the size impact on your bundle.

If you're starting with a green project, and you really want to use Angular and Material Design.  The default components[1][2] from the Angular project implement material design.  You should use them instead of the bootstrap + theme.  The bootstrap material theme is missing some interactive parts and isn't quite right for material.  Namely, the forms and buttons, however there are other bits are just off and not quite right.

If you have an existing project with bootstrap you are trying to update, then in makes more sense, and you may just be better off keeping your bootstrap based components, and updating the (s)css to use the material theme for bootstrap.  I would not recommend starting with Bootstrap with modern frameworks (or bulma and similar css based frameworks).

What I would suggest is starting with component libraries that are component-first with sane styling implementations within the library itself.  I find that material-ui[3] for React is the gold-standard when it comes to component libraries for modern development.

It's important to note that a given component library (such as material-ui) is not the same as Material Design[4] as a design concept.  The libraries implement the design pattern and some do so more closely than others.

1. https://github.com/angular/components
2. https://www.npmjs.com/package/@angular/material
3. https://material-ui.com/
4. https://material.io/design