It seems like this should be used *VERY* sparingly, it will cause a reflow in the dom and rerender at the component level. It really seems a bit backward to me.
That said, it's a nifty idea, I just think it breaks the whole point of the virtual dom, and removes many of the advantages of react.
My extent to this is I will set the size and scroll position of the document level object into the redux store, so that it can be read by many components at once.
Just don't name your objects that are deserialized or unserialized with "JSON" as part of the name.. they're an object, plain and simple...
If they hold a higher level abstraction (Json.Net object, or similar), or hold a string that is Json, go ahead and have it as part of the name... It just bugs me when I see things like:
var jsonData = JSON.parse(somestring);
If this is JavaScript, "jsonData" isn't JSON, it's an object.
Here's mine[1]. I need to button it up for an actual release, and improve the demo to show more options... it's pretty flexible and the modal is entirely standalone, with no external dependencies on the built version.
You could write a pretty thin shim for wiring up date inputs. I didn't write an actual date input component as I wanted it to be able to tie to whatever input component/method one wanted... but have a nice full-modal picker.
Also, as you resize the screen it will handle reflows/sizing as well as vertical scrolling when the window is too small, many modal templates won't do that properly. The size min+gz is about 20kb, using preact, preact-compat and redux... I'll probably refactor to separate the actual date-picker component from the modal, and make it more friendly for use inside react (and preact-compat) projects, without the bundling.
edit: the demo doesn't always seem to gzip the js, it's about 60k non-gzipped, but can shrink a bit with gzip level 5-9 compression.
[1] http://tracker1.github.io/md-datepicker/
I think Node.js should probably be the first place to reach for when building interactive front ends that need to talk to a backend... The iteration and throughput you can get with node initially make up for most of its' shortcomings. That said, you can always shave off pieces that don't perform well into services that are farther back, then use node to delegate the operations from your front end to these more performant services.
As TFA mentions, structure and discipline are important as projects grow... It's easy to create a mess of spaghetti.
Just don't name your objects that are deserialized or unserialized with "JSON" as part of the name.. they're an object, plain and simple... If they hold a higher level abstraction (Json.Net object, or similar), or hold a string that is Json, go ahead and have it as part of the name... It just bugs me when I see things like: var jsonData = JSON.parse(somestring); If this is JavaScript, "jsonData" isn't JSON, it's an object.