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 Modifier support #23

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

NullVoxPopuli
Copy link
Collaborator

@NullVoxPopuli NullVoxPopuli commented Oct 29, 2019

ez.

no existing tests to draw off of for how to test that this actually works. So my test was/is if this PR passes: ember-codemods/ember-no-implicit-this-codemod#44

except... I couldn't get it failing first... wuuuuutt

@NullVoxPopuli
Copy link
Collaborator Author

NullVoxPopuli commented Oct 29, 2019

@tylerturdenpants is this the right way to do this? or are Modifiers classified as something else. Over at ember-codemods/ember-no-implicit-this-codemod#44, I changed some things in this commit: ember-codemods/ember-no-implicit-this-codemod@aebe3e4 🤷‍♂️ I thought I needed to add modifiers to get it working... but... now I don't know what I'm doing. lol.

oh wait, yes I do. I need to remove the visitor assumption

@tylerturdenpants
Copy link
Contributor

Ya, if it is a type we can get using the built in analyzeEmberObject. When you ask “is this right?” is only when you want to collect information in any other way than the built in function. In that case you would supply your own function to do that.

@tylerturdenpants
Copy link
Contributor

I’m going to try and add more test coverage. I could use the help tho!

@NullVoxPopuli
Copy link
Collaborator Author

at the moment, this is not the right way to detect modifiers :) ember-codemods/ember-no-implicit-this-codemod@4dcb769

In that case you would supply your own function to do that.

but, in this case, since modifiers should be a built in type, we want it to be part of the default, yeah?

@tylerturdenpants
Copy link
Contributor

tylerturdenpants commented Oct 29, 2019

But, in this case, since modifiers should be a built in type, we want it to be part of the default, yeah?

I think so. Modifiers should have type like components, services, etc. However like helpers, we may need another strategy to identify them.

@rwjblue
Copy link
Member

rwjblue commented Oct 30, 2019

We might have to detect based on module path alone 🤔. Modifiers could be a class or a POJO, don’t have to extend from a common base class, etc.

I think longer term Ember should expose the getModifierManager method which would indicate that a given export is a modifier (we should do the same for getComponentManager because the same issue exists there).

@NullVoxPopuli
Copy link
Collaborator Author

I meant to debug this and see if I could detect what modifiers were -- if it has to be on path - that's fine. Last I got stuck, I needed to look up how to debug inside puppeteer. Haven't done that yet. 🙃

@tylerturdenpants
Copy link
Contributor

@NullVoxPopuli I can help you today if you want
@rwjblue, should we add the module path to the gather function arguments?

… happens to have an EmberObject as its ancestor, that is not detected. It seems only native classes are detected right now
@rwjblue
Copy link
Member

rwjblue commented Nov 2, 2019

@rwjblue, should we add the module path to the gather function arguments?

yeah, probably

@NullVoxPopuli
Copy link
Collaborator Author

yeah, probably

It's in there ;)

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 this pull request may close these issues.

3 participants