Note: this rough draft has turned into https://github.com/maxogden/art-of-node#art-of-node
go to https://github.com/maxogden/art-of-node#art-of-node to view the newer versions of this document
go to https://github.com/maxogden/art-of-node#art-of-node to view the newer versions of this document
ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats
If you rushed through David Shariff's JS Quiz or are just new to JS they might be. I know mine were. After I dried my eyes, I took the quiz again, this time very slowly trying to get at the meat behind each answer. Below is my attempt to explain each question's answer and offer some interesting permutations so that others can move beyond their hurt feelings and come out the other side better JS developers.
I initially thought I'd turn this into a blog post but think it's probably better as a gist.
Don't over think it.
var foo = function foo() {
| $(function () { | |
| //Color Stat UI component | |
| var ColorStat = flight.component(function () { | |
| this.updateColorStat = function (event, data) { | |
| var count = parseInt(this.$node.text(), 10); | |
| if (this.$node.data('color') == data.color) { | |
| this.$node.text(count + 4); | |
| } else { |
| <!-- http://jsbin.com/rageqilava/1/edit?html,output --> | |
| <script src="http://www.polymer-project.org/webcomponents.min.js"></script> | |
| <script src="http://www.polymer-project.org/polymer.min.js"></script> | |
| <link rel="import" href="templates.html" id="templates"> | |
| <polymer-element name="foo-bar"> | |
| <template> |
| // Know how fast your HTML Imports are. | |
| // crbug.com/505279 - doesn't show sub-import resources. | |
| var imports = document.querySelectorAll('link[rel="import"]'); | |
| [].forEach.call(imports, function(link) { | |
| var entries = performance.getEntriesByName(link.href); | |
| console.info('=== HTML Imports perf ==='); | |
| entries.forEach(function(e) { | |
| console.log(e.name, 'took', e.duration, 'ms'); | |
| }); | |
| }); |
| node_modules |
| /** | |
| * Creates a read/writable property which returns a function set for write/set (assignment) | |
| * and read/get access on a variable | |
| * | |
| * @param {Any} value initial value of the property | |
| */ | |
| function createProperty(value) { | |
| var _value = value; | |
| /** |
https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff
While attempting to explain JavaScript's reduce method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu
The code here captures some of the patterns I used in the "real estate" demo app discussed in my talk End to End Apps with Polymer from Polymer Summit 2017.
There are many ways to connect Redux to custom elements, and this demonstrates just one pattern. The most important aspects are to try and lazily-load as much of the otherwise global state management logic along with the components that need them (as shown via the lazyReducerEnhancer and addReducers calls in the connected components), and to consider the tradeoffs you make in terms of coupling components to the store.
The pattern shown here of creating a stateless component and then a subclass that connects it to the store addresses a potential desire to reuse app-level stateless components between more than one application context, so the subclass provides a degree of decoupling from the concrete store, at the expense of more boilerplate. If app com