-
Notifications
You must be signed in to change notification settings - Fork 440
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
V3SlotSetters linter/codemod draft #1669
base: main
Are you sure you want to change the base?
Conversation
Very cool, thanks for taking this on! Before I really dive in I have a few questions.
|
I considered it but I wanted something that would work for any templating language (or at least the most popular ones: ERB, Slim, Haml), since I use Slim in most projects.
That would be an interesting approach, but it would only work on thoroughly previewed / tested components, which is sadly not always the case 🙃 |
@Spone this is fantastic! Really great work mate. I have been putting off the big upgrade job at work but this looks like it'll get me a lot closer. Very exciting, I'm sure that the slot name changes are a blocker for quite a few people so this looks like a great solution, even if it only ended up getting 95% of the way there. I'm off for a couple of days but will give it a test on our codebase when I'm back. I think I'll probably still try to combine it with some sort of monkey-patched ViewComponent gem to hopefully log anywhere that old-style slot names are still being used after the codemod has run, just to be sure. |
I'm also planning to test this on our migration to ViewComponent 3 once I get around to it. Thanks for putting it together! I really like providing codemods as a pattern to help folks along their migration path. We could tuck this inside a generator that helps folks to handle migrations, similar to Rails' own |
@Spone I like it! Are you hoping to land this in a Release Candidate ahead of 3.0.0 landing? |
@joelhawksley I'd love to, if I get sufficient feedback from people who tried it! I ran this on more codebases, and noticed a few false-positives that I'd like to fix as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think others will find this tool helpful. Would it be worth writing a simple test for it? We don't need to be too thorough.
# | ||
# ViewComponent::Codemods::V3SlotSetters.new.call | ||
# | ||
# If your app uses custom paths for views, you can pass them in: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we load these from the rails config instead of requiring them to be passed in?
@Spone I'm hoping to wrap up the v3 release cycle in the next week or two, so perhaps you could decide whether to land this in the next week? |
Ran this against our codebase @fac. I'd already gone through and made all the necessary changes previously on another branch. When I ran this before I had updated the slot syntax, it came up with a lot of When I ran this after I had updated the slot syntax, it didn't turn up any cases at all, which I'm hoping suggests that I had found everything that needed to be fixed. Ideally, I think it would be really good to use |
@Spone are you still interested in landing this PR? I'd be cool either way but I'm trying to get a feel of what we'd like to land with v3 final. |
@joelhawksley Sorry I missed your previous comment. I'd like to continue improving this but I cannot commit to a specific time frame. I feel like this can be part of an upcoming v3.x minor version release. What do you think? |
Co-authored-by: Joel Hawksley <joel@hawksley.org>
Co-authored-by: Joel Hawksley <joel@hawksley.org>
I'd be open to pairing with someone to wrap this up! |
rendered_components = [] | ||
content = File.read(file) | ||
|
||
if (render_match = content.match(RENDER_REGEX)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this assuming only a single render_match per file?
If I render multiple different components in the same file, would this catch it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After re-reading the code, I guess you're right. I'm a bit surprised I didn't catch this earlier 😅
This part needs to be reworked.
@Spone what's left here in order to get this ready for merge? Some suggestions I have:
|
@kirillplatonov I added a "What's left to do" section to the PR description, including your suggestions. Would you like to take care of some of these items? |
@Spone sure! Should I open a PR with my changes to |
Yes please do! |
* Add rake task for legacy slots detection * Add view component previews to codemod view paths * Autodetect rails view paths * Improve uncertain matches detection * Update lib/view_component/codemods/v3_slot_setters.rb Co-authored-by: Hans Lemuet <Spone@users.noreply.github.com> * Update usage instruction * Add rake task to migrate to new slots * Update changelog * Standardrb * Add tests * Call eager loading via Rails * Update docs/CHANGELOG.md Co-authored-by: Hans Lemuet <Spone@users.noreply.github.com> * Add support for passing view paths via CLI * Fix helper in rake tasks * Fix tests * Add note about codemod to changelog --------- Co-authored-by: Hans Lemuet <Spone@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might we add something to the docs for this?
Yes, but not sure where. We don't yet have a "Upgrading" page. Also, we need to fix the changelog, the entry has to be under the |
How about adding a note to the Slots docs? |
Hey guys! I started working on a similar solution last week and had no idea! At eXp-Realty we use a lot of View Components and have 10+ production apps with them in them. I built a Ruby script to automatically update these slot calls with the |
Hey @Spone, how's this PR coming along? Is it ready to merge? |
Haven't had time to look at this again before holidays, I'll get back to it when I'm back to work. Thanks everyone for your patience 🙏 |
Just used that script to great effect, TY! Noted a small issue with encoding and have opened a PR against your repo if you'd like. |
@Spone how do you think we should proceed with this PR? |
Thanks @JWShuff ! I'm glad it worked well for you. I merged your PR on my script |
@Spone I would really love to see this go through, if you need my help in getting it over the line please ask me as I would love to help if its needed |
What are you trying to accomplish?
I'd like to provide a linter / codemod to ease the upgrade to ViewComponent v3.0.0, especially the new slot setters syntax which is in my opinion the main hassle when upgrading.
For now, this draft only outputs suggestions of changes. If we're confident enough we don't have false positives, we can change it to actually modify the files (or allow running it as a linter or as a codemod).
What approach did you choose and why?
I first tried to experiment with Ruby AST / Parser-based solutions, but given that we have to access the slot names in ViewComponent classes and parse the content of various templates (erb, slim, haml), it did not appear as a viable solution.
Then, I implemented a two-steps approach:
render
s of the components, called with blocks, and methods matching the name of their slots' setter methods. These suggestions are prefixed withprobably
in the output ;render(MyComponent.new)
), this was not enough to find all occurrences so I added another "uncertain matches" step: try to match the name of the slots in all files. These suggestions are prefixed withmaybe
in the output.I tested this on several projects, here is the output:
Anything you want to highlight for special attention from reviewers?
I packaged this as a class that could be included to the gem.
The exact way people can run this remains to be defined.
We also have to figure a way to test this :)
What's left to do
render_match
standardrb --fix
orrubocop -A
)