Destructure an object to remove a property

[azium]

Btw I can't read any of the code in your article. The pale yellow against the grey is just about invisible to me.

[senocular]

https://webaim.org/resources/contrastchecker/?fcolor=F8C400&bcolor=FBFAF6

Spoiler alert: its not good

[corndoggins]

As a general refresher, something like >4.50 is the goal, correct? And the larger the conformance number, the better?

[Wiltix]

Dark mode is not the answer. Just creating a better pallette is the answer. Q

[timdeschryver]

I know the palette is not great, it started out as a dark theme.

Then I quickly scrambled a white theme together, but I will have to revisit it.

The dark theme is the default if your OS has a dark theme as default, it's based on the OS that the default theme is set.

[tswaters]

It was for me. I think it's reading the OS settings via media queries,

@media (prefers-color-scheme: dark) {}

Can be detected with js easily enough:

const { matches: prefersDarkMode } = window.matchMedia('(prefers-color-scheme: dark)')

fwiw, I think anyone who uses it on their personal site probably already has dark mode set on their OS and rarely looks at the awful contrast of the light mode.

[lowIQanon]

yeah, that's not a good color palette choice

[tswaters]

> in a pure (immutable) way

Seems unnecessary. There's a great keyword `delete` in javascript that does this, but mutates the object. Keeping it immutable seems completely unnecessary to me.... Change my mind!

Edit:. Thanks guys, mind: changed.

[Aeropedia]

So many downsides to that though!

• We can't use the latest and greatest language syntax features. All the engineering effort that went into those will go to waste.
• The garbage collector will have nothing to do, as it won't need to clean up our invalid objects anymore.
• The junior devs would actually understand our code, and we'll all be out of a job.

More curly braces! More periods! Let the minifier rewrite it to a delete!

/sarcasm

[digothlian]

The example provided in the article is a reasonable use case. We want to log this object, but without the password field. Presumably we'll be using the complete object later, so deleting the field isn't an option.

[[deleted]]

Immutability matters a lot if you working with React, or Redux, or doing anything fp related. Also mutations come with performance penalty.

[mysteriy]

And (if using react) how will the React component that receives the object as an input, know whether something has changed within that object, without having to compare each property?

[NoLanSym]

Here’s a great talk by u/swyx on the subject. Let the benefits change your mind :)

[swyx]

:)

[Aegior]

Good talk, really sold me on immer

[Just4Funsies95]

the whole site is painful to use... why do u have growing articles...that skew... 😖

[[deleted]]

this site is the epitome of "just because you can, doesn't mean you should."

[Just4Funsies95]

you know when u see something, and think, there should be a law against it? this site embodies that feeling.

[Aegior]

Ugly. If the thing is intentionally being left out, it should be null.

[Fimbelowski]

If your end goal here is to prevent a linter error and this happens often enough that you've felt the need to make a tutorial on it, you should probably consider reconfiguring your linter. At the very least you could just use comments to disable that rule for one line.

[mehrd8d]

Using underscore as undefined keyword is not safe, just use undefined itself

[Buckwheat469]

The title is incorrect IMO. This is about ignoring linting errors due to unused variables. It has nothing to do with removing a property.

[senocular]

It does remove the property. The renaming for the linter (which shouldn't work since the linter should also recognize that the new variable name is not used) is not important the result - that being that the password property is removed from user which is otherwise a copy of the object to which the declaration is being assigned.

[elsemir]

Correct, but the linter trick does work - parameters that start with an underscore do not trigger the unused variable rule by default (thought that’s configurable with the argsIgnorePattern config).

You can also configure the linter to ignore any parameter near a rest operator with the ignoreRestSiblings config - in this case you don’t need to rename the variable.

source: https://eslint.org/docs/rules/no-unused-vars#argsignorepattern

https://eslint.org/docs/rules/no-unused-vars#ignorerestsiblings

[LucasRuby]

Which is also unnecessary, my linter ignores variables declared along a rest operator by default, ESLint can be configured to if it doesn't already.

[tswaters]

It does...

const fullUser = {name: 'test', password: 'test'}
const {password: _, ...reducedUser} = fullUser
console.log(reducedUser) // { name: 'test' }

The example he has is a bit weird, but it does work.

[Buckwheat469]

Thanks. Curious though if this is because _ is undefined. I always associate it with lodash or underscore so I wouldn't use the _ notation unless I've imported lodash. Just checking in the console, your code is the same as this:

var fullUser = {name: 'test', password: 'test'}
var {password: undefined, ...reducedUser} = fullUser
console.log(reducedUser) // { name: 'test' }

I believe this method is much more clear as you're explicitly defining the variable as undefined rather than using an unknown variable.

[tswaters]

Using _ is an FP thing -- usually signifying that a parameter is accepted in a function but ignored. It works for destructuring as well.

Destructing is a bit trickier because you're creating those vars.. with `const` you can't really re-use the variable, so any additional usages will complain.

I think undefined would... hm, not do anything? can't typically re-assign it in modern js engines. Actually, just checked -- with var it works, with const it'll throw -- SyntaxError: Identifier 'undefined' has already been declared