I say "animated gif" but in reality I think it's irresponsible to be serving "real" GIF files to people now. You should be serving gfy's, gifv's, webm, mp4s, whatever. They're a fraction of the filesize making it easier for you to deliver high fidelity, full color animation very quickly, especially on bad mobile connections. (But I suppose if you're just doing this for small audiences (like bug reporting), then LICEcap is a good solution).
| var elements = document.querySelectorAll("div"), | |
| callback = (el) => { console.log(el); }; | |
| // Spread operator | |
| [...elements].forEach(callback); | |
| // Array.from() | |
| Array.from(elements).forEach(callback); | |
| // for...of statement |
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| nodeValue is a little more confusing to use, but faster than innerHTML. | |
| innerHTML parses content as HTML and takes longer. | |
| textContent uses straight text, does not parse HTML, and is faster. | |
| innerText is IE specific and also takes styles into consideration. It won't get hidden text for instance. | |
| http://stackoverflow.com/questions/21311299/nodevalue-vs-innerhtml-and-textcontent-how-to-choose |
[12:03 AM] acemarke: "controlled" and "uncontrolled" inputs
[12:04 AM] acemarke: if I have a plain, normal HTML page, and I put <input id="myTextbox" type="text" /> in my page(edited)
[12:04 AM] acemarke: and I start typing into that textbox
[12:04 AM] acemarke: it remembers what I've typed. The browser stores the current value for that input
[12:05 AM] acemarke: and then sometime later, I can get the actual element, say, const input = document.getElementById("myTextbox"), and I can ask it for its value: const currentText = input.value;
[12:05 AM] acemarke: good so far?
[12:08 AM] acemarke: I'll keep going, and let me know if you have questions
[12:08 AM] lozio: ok, actually I'm reading
[12:09 AM] lozio: good
[12:09 AM] acemarke: so, a normal HTML input field effectively stores its own value at all times, and you can get the element and ask for its value
| ; The Expression Problem and my sources: | |
| ; http://stackoverflow.com/questions/3596366/what-is-the-expression-problem | |
| ; http://blog.ontoillogical.com/blog/2014/10/18/solving-the-expression-problem-in-clojure/ | |
| ; http://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ | |
| ; http://www.ibm.com/developerworks/library/j-clojure-protocols/ | |
| ; To begin demonstrating the problem, we first need some | |
| ; "legacy code" with datastructures and functionality: |
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
