Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for objects/functions defined outside of JSX but inside render #7

Closed
OliverJAsh opened this issue Dec 8, 2017 · 6 comments · Fixed by #15
Closed

Support for objects/functions defined outside of JSX but inside render #7

OliverJAsh opened this issue Dec 8, 2017 · 6 comments · Fixed by #15

Comments

@OliverJAsh
Copy link

We report on:

  render() {
    return <Tag obj={{}} />
  }

But it's easily defeated with:

  render() {
    var o = {}
    return <Tag obj={o} />
  }

#6 (comment)

@n1313
Copy link

n1313 commented Jan 8, 2019

This rule is the one that is most often violated, I think, and it is unfortunate that it can be so easily defeated. I'm interested in getting this improved, but I'm totally new to eslint plugins. How would one go about contributing to this?

Also, what would be the recommended way of correcting this violation in class-based components? Static declarations outside of component? Class properties?

@cvazac
Copy link
Owner

cvazac commented Jan 9, 2019

Trying to solve this using eslint-scope, but this will not be straight forward take some time to get right (but I think I can make it happen!). The logic I'd like to apply: if the variable used in the JSXAttribute was assigned the value of [[], {}, etc] in the same scope as the JSXAttribute, report the violation.

Violations:

returnMarkup(o) {
  o = {}
  return <Tag obj={o} />
}

Not Violations:

returnMarkup(o) {
  o.val = 123
  return <Tag obj={o} />
}
returnMarkup(o) {
  o = p
  return <Tag obj={o} />
}

@n1313 - Yes, static or even instance variables would work. If you can point me to your component/violation, I could make a better recommendation if you like. :)

@n1313
Copy link

n1313 commented Jan 10, 2019

Should this be a violation?

getO() {
  return {}
}
returnMarkup() {
  const o = this.getO();
  return <Tag obj={o} />
}

@cvazac
Copy link
Owner

cvazac commented Jan 10, 2019

It's a performance hit, but I don't think that that can be a violation to a linter. getO could be overwritten at execution time, for example, and the linter couldn't know that.

@OliverJAsh
Copy link
Author

getO could be overwritten at execution time, for example, and the linter couldn't know that.

That's possible but it seems unlikely. If that was the case, the lint rule could be disable for this line? I would prefer to err on the side of strictness—we have a lot of methods, called inside render, which return new objects used as props.

@cvazac
Copy link
Owner

cvazac commented Jan 10, 2019

Yes, it's unlikely. :)

I just think it gets super tricky when you start mixing runtime with static code linting. Would this be a violation?

getO() {
  return FLAG_THAT_IS_ALWAYS_FALSE ? {} : STATIC_OBJECT
}

Or consider inheritance:

render () {
  return <Item arg={getValue()} />
}

I don't think a linter could know how to look for all of the possible child classes to know exactly which getValue() is actually being executed.

If you can find an example of a linter making runtime decisions or "stepping into" other functions, I will happily give it a shot. :)

But I think I can get something working in the "simple case", if you are willing to try it out before it ships, I would be very grateful, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants