191–200 of 250 posts
Earlier quoted context omitted.
It's both amazing, and 600MB worth of dependencies. We use it for server-side code. It's high quality, and we only have a few issues with it, but I can't wait to be able to ditch is (pretty much when async/await lands in a stable node).
600MB worth of development dependencies, which don't effect the code being sent to the client. Just wanted to clarify.
"best practices": "use class instead of manipulating prototype directly" Who comes up with these "rules"? This is not a hard and fast rule. Manipulating the prototype of an object is not "dangerous". I'm sick and tired of some loud mouth saying something is dangerous without explaining why. WHY? Why it it dangerous? Don't talk at me. Provide me a sound reason and case to justify what you say. Talk is cheap. It makes…
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This has some warnings at the top as to why.
One points to the parent of an object and the other points to the object's prototype (which in turn has it's own `__proto__ property). Accessing `prototype` is just fine, but if you want to access `__proto__` then you should use `Object.create()` instead.
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)
Indeed. Are there any 'good' strategies for this (loading ES6 for supported browsers)? I imagine you'd have to do UA sniffing on the server side, and I suppose it's kind of a moot point if you're using React/JSX.
Earlier quoted context omitted.
I'll give you two reasons: performance and ease of use. When you need a copy of a large object with a small change, performing the copy with native JS is going to be slower than doing it with a specialized data structure like a hash mapped trie[0] (which is what Immutable.js uses). Also, if you're trying to keep your data truly immutable, that copy operation is going to be a pain to write with the built-in tools, whe…
> When you need a copy of a large object with a small change, performing the copy with native JS is going to be slower than doing it with a specialized data structure like a hash mapped trie[0] (which is what Immutable.js uses) Fair enough though I'm not convinced you should be hitting this type of use case in your code (kinda inefficient and sounds awkward to make a small change to a large object and yet need both o…
> While it is a little bit of a pain almost every framework and probably half of the libraries in existence on npm have a copy function.
The problem isn't just the usability of the copy operation (and even if it were, you still have the performance issue); there is also the problem of JavaScript not enforcing immutability of nested objects with Object.freeze. So if you want to enforce that, you're going to have to call Object.freeze on every child object, which becomes a nightmare to write and maintain.
Earlier quoted context omitted.
Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? While I agree that const/let is a useful convention for communicating mutability, it isn't nearly a big enough deal to warrant the attention it receives from the community. It's not just const/let; I rarely make a front end PR that isn't bike-shedded to death over subjective styling choices, sin…
> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? - Tabs vs spaces. - Vi vs Emacs - Weak vs strong typing - where to place {} in block statements - where to put commas No, programming in general is susceptible to these trivial holy wars.
Earlier quoted context omitted.
> immutablejs might be overkill, but not having, and using, a recursive freeze is going to bite a lot of people if the advice is just 'const + Object.freeze'. No one should be trying to use a recursive freeze (if they are I would argue their data structure is poorly suited to be immutable). I'm not saying `const` + `Object.freeze()` gets you Immutablejs I'm saying it gets you, likely, what you want / need.
Our team was just hit with this: const x = Object.freeze([ {id: 1, value: 'foo'}, {id: 2, value: 'bar'}, {id: 3, value: 'baz'}, ]) ... //Bug in the code x[0].value = 'test' First comment on the bug report was: 'This shouldn't be possible as the array is const and frozen'. their data structure is poorly suited to be immutable An array of object seems completely reasonable. Even an array of objects, where those objects…
Yeah const and Object.freeze() are not exactly the most intuitive depending on your level of JavaScript internals knowledge (and even then I don't think const is very intuitive but I digress).
> We'll just have to agree to disagree.
Fair enough! I would just caution trying to make complex objects immutable; it can be handy if you're developing a library and don't trust the dev on the other side (to a degree, copying may be preferable depending on the context) but it can complicate things and lead to some performance and development pattern issues.
Earlier quoted context omitted.
It depends I think. For example, in my opinion const Header = ({ children, iconName, iconSize, title }) => { ... }; is more readable than const Header = (props) => { ... };
const Header = ({ children, iconName, iconSize, title }) => { ... }; Once you get used to the destructuring parameter idiom, sure. It also conveys more information. But that statement is overloaded in that it makes use of implicit object shortcuts which has a bit of a learning curve for longtime ES5 users. const Header = ({ children: children, iconName: iconName, iconSize: iconSize, title: title }) => { ... }; When o…
function thisIsBad ({
someKey: renamedSomeKey,
someOtherKey: renamedSomeOtherKey = 'otherDefaultValue',
meta: { innerMetaKey = 'someInnerMetaKeyValue', otherInnerMetaKey, ...remainingMeta }
} = {
someKey: 'defaultValue',
someOtherKey: SOME_CONSTANT,
meta: {}
}) {
// ...
return { someKey: renamedSomeKey }
}
This is syntax which can simplify your code if you apply it carefully, but will ruin your code if you over-use it.
var's function scope is a feature! You don't have to place variable declarations in the header! (they are hoisted) Placing the var declarations where they are used makes the code easier to understand. The point of constructor functions is not having to write new . So classes does nothing besides syntactic sugars over the prototype system, witch actually makes it more complicated and the code harder to maintain. Async…
Arrow functions get auto-named in many browsers based on how they are used. This auto-naming is actually being somewhat standardized between browsers and means there is no difference between anonymous-style function () {} and arrow functions. Promises are more than just a wrapper around callbacks because they also standardize behavior between "stacks" of callbacks, by instead "chaining" them and creating a standard i…
If you want to call everything in serial and wait between each step, why not make it synchronous instead of .then chaining ?
Earlier quoted context omitted.
> When you need a copy of a large object with a small change, performing the copy with native JS is going to be slower than doing it with a specialized data structure like a hash mapped trie[0] (which is what Immutable.js uses) Fair enough though I'm not convinced you should be hitting this type of use case in your code (kinda inefficient and sounds awkward to make a small change to a large object and yet need both o…
Sorry, that might have come off a bit harsh. I was just trying to make the point that Object.freeze doesn't give you nearly 99.9995%, nor even 95%, of what immutable data structures give you. I don't think the apps I'm working on are particularly complex, but if you're using a Flux architecture with something like React/Redux, this is a very common pattern, and it doesn't take long to get to a point where the gains i…
Sure. That's why I made sure to say it'll give you 99% of what you want. Not 99% of immutable data structure capabilities :).
Though I'm sure folks may disagree with what I'm suggesting they "want" but I do not believe it's a good pattern to follow where a complex object needs to be immutable in JavaScript.
> JavaScript not enforcing immutability of nested objects with Object.freeze. So if you want to enforce that, you're going to have to call Object.freeze on every child object, which becomes a nightmare to write and maintain.
Which is why you should never ever do that. It's a bad pattern in a dynamic language to try and make complex structures completely immutable. It's best to simply find alternative ways of accessing them if you do not want to expose it to modification.
Earlier quoted context omitted.
const Header = ({ children, iconName, iconSize, title }) => { ... }; Once you get used to the destructuring parameter idiom, sure. It also conveys more information. But that statement is overloaded in that it makes use of implicit object shortcuts which has a bit of a learning curve for longtime ES5 users. const Header = ({ children: children, iconName: iconName, iconSize: iconSize, title: title }) => { ... }; When o…
function thisIsBad ({ someKey: renamedSomeKey, someOtherKey: renamedSomeOtherKey = 'otherDefaultValue', meta: { innerMetaKey = 'someInnerMetaKeyValue', otherInnerMetaKey, ...remainingMeta } } = { someKey: 'defaultValue', someOtherKey: SOME_CONSTANT, meta: {} }) { // ... return { someKey: renamedSomeKey } } My favourite messed up part of the syntax is the way the `:` character is used to describe either the default va…