-
-
Notifications
You must be signed in to change notification settings - Fork 381
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
feat: Adding codemods in loadable-codemod #463
Conversation
|
||
const CustomLinkLoadable = loadable(() => | ||
import(/* webpackChunkName: "custom-link" */ '@components/CustomLink/Link'), { | ||
fallback: null, |
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.
it should throw in this case, as long as some user logic is going to be lost.
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.
Ah, I am having quite a bit of dilemma with that one. I assume if we were to throw in that case, the codemod would be quite unusable.
I do not have a number, but I assume the number of people using that pattern should be quite big, especially because it's in the README.md of the project. 🤔
Would be happy to get additional perspective regarding this one!
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.
Would it make sense to solve this by extending loadable-components
so that the fallback can be either an element (like today) or a render function/component, like react-loadable
?
Something like React.isValidElement(fallback) ? fallback : React.createElement(fallback, props)
should be enough. I guess the problem might be figuring out whatever props
should be...
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.
Since react-loadable
has some behaviours that don't exist in @loadable/component
, I am not sure if there is a way to make the change without changing some logics; unless of course @loadable/component
adds the same APIs that implement the same behaviours.
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.
Yeah, I get that. A sort of halfway there solution could be to wrap the inline function/loading component in a React.createElement
call with no props. This would at least render the default state and preserve the existing code.
The transform should probably still write something to the console about that loading components aren't fully supported and that additional action might be needed.
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.
Just added it! Please kindly review it again 🙂
I like the idea 🤩 |
I think there is only one step before getting the world's best, as well as the world's first codemod of this type -
|
Sorry for the late reply, work has been busy these past few weeks 😞 Alright, from what I read, the summary is:
I will try to find the time to work on this, hopefully soon. |
Thanks! |
Summary
This package is a collection of codemod using
jscodeshift
that can be used to help making big changes easier to a project, for example: migrating fromreact-loadable
to@loadable/component
This PR setups this in a new package named
loadable-codemod
and provide thereact-loadable-to-loadable-component
transform.Test plan
All tests are put inside
codemod/transform/__tests__
.Tests are written as such:
This will check for the file
react-loadable-to-loadable-component_expr.input.js
inside@loadable/codemod/transform/__testfixtures__
, feed it into thereact-loadable-to-loadable-component
transformer, and assert that the output is equal toreact-loadable-to-loadable-component_expr.output.js
Notes
There might be some cases that I haven't accounted for, so any help in improvement would be great! cc: @neoziro
As per @jonatansberg's input, instead of rendering
null
when there is a use case where@loadable/component
can't handle, we will render a reasonable default, while logging warning messages.The props we will be passing to the
loading
component will be as following: