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

Add eslint rule to find unused properties, data and computed properties #5347

Merged
merged 13 commits into from Apr 8, 2019
Merged

Add eslint rule to find unused properties, data and computed properties #5347

merged 13 commits into from Apr 8, 2019

Conversation

MisRob
Copy link
Member

@MisRob MisRob commented Apr 6, 2019

Summary

  1. Implement eslint rule that reports unused properties, data, and computed properties
  2. Turn it on and deal with it
  3. The last commit contains fix for the following issue: One of the reported errors showed that there was a development mock label in a group exercise lesson report link leading back to a parent lesson page (Coach -> Reports -> Groups –> select a group lesson <lesson_title> -> select an exercise belonging to this lesson and watch backlink label (should be 'Back to "<lesson_title>"' but was 'Back to “Lesson 1"')

Before
before

After
after

Reviewer guidance

  • Break it :)! Any ideas about possibly untreated situations or edge cases?
  • I tried to be careful and check that there is no hidden usage for all properties removed in
    055bfc3 , though I would appreciate if someone had a look
  • In 582dcab I removed constants from properties. This could also be solved be leaving them in properties but referencing them using this. I guess there's no need to save them to an instance and it's also a bit more visible that they are some common definitions and constants, but I don't have any preference so if someone prefers the second solution, no problem.
  • In 9ca2dae I commented out all unused properties related to to commented out template TODO code. I could remove everything but I suppose that it is under development? If it's not the case, I'll remove everything including those template parts.

References

Partially solves #4992.


As discussed in #4992, as soon as it's ready, I would like to open the rule PR directly in eslint-plugin-vue repo where there's already an issue for this rule opened and proposal accepted.


Contributor Checklist

PR process:

  • PR has the correct target branch and milestone
  • PR has 'needs review' or 'work-in-progress' label
  • If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
  • If this is an important user-facing change, PR or related issue has a 'changelog' label
  • If this includes an internal dependency change, a link to the diff is provided

Testing:

  • Contributor has fully tested the PR manually
  • If there are any front-end changes, before/after screenshots are included
  • Critical user journeys are covered by Gherkin stories
  • Critical and brittle code paths are covered by unit tests

Reviewer Checklist

  • Automated test coverage is satisfactory
  • PR is fully functional
  • PR has been tested for accessibility regressions
  • External dependency files were updated if necessary (yarn and pip)
  • Documentation is updated
  • Contributor is in AUTHORS.rst

Michaela Robosova added 7 commits April 6, 2019 16:35
Those constants are referenced directly,
they're actually not used as a component
instance data.
that are needed for TODO template commented
out code.
@MisRob MisRob added the work-in-progress Not ready for review label Apr 6, 2019
@MisRob MisRob added this to the 0.12.y milestone Apr 6, 2019
@codecov
Copy link

codecov bot commented Apr 6, 2019

@MisRob MisRob added TODO: needs review Waiting for review and removed work-in-progress Not ready for review labels Apr 6, 2019
@MisRob MisRob added the TAG: dev experience Build performance, linting, debugging... label Apr 6, 2019
Copy link
Member

@rtibbles rtibbles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is excellent. My read through of the code changes and the linting code make me think this is definitely close to mergeable, but as you suggest, I will also try to break it myself!

@@ -79,6 +79,7 @@
group() {
return this.groupMap[this.$route.params.groupId];
},
/** TODO COACH
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks unfinished?

@@ -93,6 +93,7 @@
components: {},
mixins: [commonCoach],
computed: {
/** TODO COACH
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@indirectlylit
Copy link
Contributor

indirectlylit commented Apr 6, 2019

awesome!

I tried to be careful and check that there is no hidden usage for all properties

One thing to check for is that many of the users of these components will still be passing in the props. For example, we deleted id from TaskProgress but that prop is still being passed in.

I removed constants

We had a related conversation a little while go. The general pattern is that some thing in <script> needs to be accessed in <template>, and then we've tended to do one of:

  • put this.thing = thing; or this.$options.thing = thing; in mounted() or somewhere similar
  • put thing in data()
  • put thing() { return thing; } in computed props

There are lots of these scattered around the code base. I don't think the inconsistency has caused us any particular issues, but might be nice to standardize on a strategy.

I commented out all unused properties related to to commented out template TODO code

I think some of these relate to some 0.12.y coach tools work @jonboiser is working on. @jonboiser would you mind checking if any of these are actually dead code that should be removed?

@MisRob
Copy link
Member Author

MisRob commented Apr 7, 2019

Thanks for info Devon!

One thing to check for is that many of the users of these components will still be passing in the props.

Right, I didn't realize I should also clean this, thanks. It's done in the last four commits.

We had a related conversation a little while go. The general pattern is that some thing in <script> needs to be accessed in <template>, and then we've tended to do one of...

OK. It was used only in the script part here but I guess it will be better to keep it consistent and prepared for usage in templates so I moved those constants I removed before back to an instance and referenced them using this (2934966).

@indirectlylit
Copy link
Contributor

I guess it will be better to keep it consistent and prepared for usage in templates

all right, that's cool. The way you had it before also seemed fine though

@MisRob
Copy link
Member Author

MisRob commented Apr 8, 2019

No problem, I don't have any strong opinion on this particular issue and if this is a general tendency ;)

Copy link
Contributor

@indirectlylit indirectlylit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna go ahead and merge this to prevent merge conflicts.

@jonboiser when you get back, could you follow up on the 'TODO' items and flag if there are any that won't be addressed by your work on coach tools?

@indirectlylit indirectlylit merged commit c3af46e into learningequality:develop Apr 8, 2019
@jtwaleson
Copy link

This is great!! Are there any plans to add this to eslint-plugin-vue? Could an update be pushed to NPM so we can use these rules via eslint-plugin-kolibri?

@MisRob
Copy link
Member Author

MisRob commented May 4, 2019

Hello, we opened a PR in eslint-plugin-vue repository one month ago, you can find it here vuejs/eslint-plugin-vue#871 with some more info regarding updates and other, similar, rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TAG: dev experience Build performance, linting, debugging... TODO: needs review Waiting for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants