Asked  3 Months ago    Answers:  5   Viewed   362 times

I've applied eslint airbnb standard to my code, so now this code:

handleSubmit = (event) => {
  event.preventDefault();
  this.props.onSearch(this.query.value);
  event.target.blur();
}

causes this error:

[eslint] Must use destructuring props assignment (react/destructuring-assignment)

onSearch basically a trigger that passes up a value to parent component.

How do I refactor this code to meet the eslint requirements?

 Answers

19
handleSubmit = (event) => {
    event.preventDefault();

    const {onSearch} = this.props
    const {value} = this.query
    onSearch(value)

    event.target.blur();
}
Friday, July 30, 2021
 
user2725742
answered 3 Months ago
12

It's a bit buried in the documentation, but if you add some things to the 'extends' property, you can use both the rules recommended by ESLint like no-unused-vars, and have it actually work in Typescript. Like so:

"extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended"
    ],

@typescript-eslint/recommended seems to be the thing that allows eslint:recommended to deal with Typescript constructs effectively. Not sure how it would affect your other extensions though.

Wednesday, June 23, 2021
 
Sidarta
answered 4 Months ago
68

Either change your file extensions to .jsx as mentioned or disable the jsx-filename-extension rule. You can add the following to your config to allow .js extensions for JSX.

"rules": {
  "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
}
Saturday, July 10, 2021
 
csi
answered 4 Months ago
csi
93

As a general point: it is easy to turn strings into WORD!s (e.g. to-word "foo"). However, it can be tough to magically make that WORD! reference be bound to "the variable you meant". The wily reasons for this have to do with the fact that there is no scope. See:

Is there a overall explanation about definitional scoping in Rebol and Red

So what you are trying to do is going to be a little dodgy regardless. There are better ways. But to try to avoid un-asking the question, I'll explain what's happening here and how to fix it in the style you were attempting.

corrected version is for instructional purposes only. please do this another way.

compose rejoin [namelist/:i "f/text"]

REJOIN is applied to blocks, and merges the contents, with a result type loosely based on the first element. (It's a questionable operation, but historically popular in Rebol code.)

Since namelist/:i is a string, your REJOIN will produce a string...and this string will wind up being passed to COMPOSE. But COMPOSE is meant to be applied to BLOCK!s...and searches for parenthesized groups inside of it, evaluating them while leaving the rest of the code alone. It's a kind of templating system for blocks, with no effect on other kinds of input...so you'll get the same string out.

TO-SET-PATH is thus being fed a STRING! (e.g. "var1f/text"). I didn't even know that path conversion accepted strings. I find the behavior of this operation to be puzzling, because it apparently LOADs the string and then makes it the singular element of a length 1 SET-PATH!.

>> p: to-set-path "foo/bar"
== foo/bar: ;-- huh? really, did that work?

>> type? p
== set-path! ;-- ok, good, I guess.

>> length? p
== 1 ;-- wait, what?

>> type? first p
== path! ;-- a PATH! inside a SET-PATH!...?

>> length? first p
== 2

>> type? first first p
== word!

>> foo: 10
>> get first first p
== 10 ;-- well, at least it's bound

That's not making the kind of SET-PATH! you want; you want a SET-PATH! with 2 WORD! elements. Converting a BLOCK! to a SET-PATH! would be a way of doing this.

to-set-path compose [(load rejoin [namelist/:i "f"]) text]

Now we see COMPOSE being used correctly, where it will run the evaluation inside the parentheses and leave the text word alone. This produces a block with 2 elements in it, which is easily converted to a SET-PATH!. I'm using LOAD instead of TO-WORD to take care of some of the "magic" of connecting to an actual variable that plain word conversion would not do. But it's just a workaround--not a sure thing, and won't always be the answer to the problem.

But producing a SET-PATH! doesn't mean it runs. If I say:

s: to-set-word "x"
probe type? s

No SET-WORD! is executed, it's merely generated. And in this case, stored in the variable s. But if I hadn't stored it in a variable, the evaluation product would have just been thrown out...the way 2 is simply thrown out if I write 1 + 1 print "hi". To execute the SET-PATH!, you need to put it in a context where it will be composed into source and evaluated.

(Note: Ren-C has a primitive called EVAL which can do this on the fly, e.g. eval (quote x:) 10 will assign 10 to x.)

But in Red you'll need to do something like this:

namelist: ["var1" "var2"]
var1: 5
var2: 10

process: [
    repeat i length? namelist [
        do probe compose [
            (to-set-path compose [(load rejoin [namelist/:i "f"]) text])
            to-string
            (load namelist/:i)
        ]
    ]
]

lay: layout [ 
    text "Values to appear here: "
    var1f: field "a"
    var2f: field "b"

    button "Click" [do process]
]

view lay

Now your outer COMPOSE is building an 3-element block, where the first element will be a SET-PATH!, the second a WORD! that was literally left alone to convert your integer to a string, and the third a WORD! that will be evaluated to the relevant integer. The DO of that block will have the assignment effect.

I changed your to-word namelist/:i to load namelist/:i. Again, for the reason I mentioned...TO-WORD alone doesn't put on a "binding".

I left a PROBE in there so you could see what is built and executed:

[var1f/text: to-string var1]
[var2f/text: to-string var2]

PROBE is a very helpful tool, which outputs its argument but also passes it through. You can insert it at various points in your code to get a better understanding of what's going on.

(Note: If you're wondering why I don't suggest writing a narrow EVAL-2 helper operation that only works for SET-PATH!, it's because such a thing exists with a better name. It's called SET. Try set (quote x:) 10 then print x. In fact, variants of this is how you'd actually want to do things... obj: make object! [a: 10] then set (in obj 'a) 20 then print obj/a. As I said, there's a lot better ways to go about what you're doing, but I tried to stay focused on doing it the-way-you-were-trying.)

Saturday, August 28, 2021
 
aphoria
answered 2 Months ago
59

What eslint is telling you with the react/destructuring-assignments error is that assignments like:

const data = this.state.data;

can be rewritten into:

const { data } = this.state;

This also works for function arguments, so:

onChange = e => { ... }

can be written as

onChange = ({target: {value, name}}) => { ... }

The next error for react/no-access-state-in-setstate tells you that you are writing:

this.setState({
    data: { ...this.state.data, [e.target.name]: e.target.value }
});

when you should be writing:

this.setState(prevState => ({
    data: { ...prevState.data, [e.target.name]: e.target.value }
}));

or, if you combine it with the react/destructuring-assignments rule:

onChange = ({target: {name, value}}) =>
    this.setState(prevState => ({
        data: { ...prevState.data, [name]: value }
    }));

You can read more about those two rules here:

react/destructuring-assignment

react/no-access-state-in-setstate

Thursday, September 16, 2021
 
Alex Okrushko
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :