Loadable-components: react-loadable compatibility component

Created on 26 Jun 2019  路  10Comments  路  Source: gregberge/loadable-components

馃殌 Feature Proposal

For easier migrating from react-loadable this library can offer a Loadable HoC that wraps error handling, timeout and retries automatically. This component should conform to react-loadable API so users can easily switch to this component by simply aliasing the dependencies.

Motivation

To migrate our large repo we had to do a large refactoring change. We also lost automatic handling of timeouts and retry functionality. We had a global <Loading /> component that was consuming react-loadable props.

Pitch

This will make adopting the component framework super easy

feature request 馃檹

Most helpful comment

Maybe the complexity does not worth it. Also the API provided by React Loadable is not in the philosophy of React. For example, errors should be handled with Error Boundaries (as React.lazy), so it does not encourages good practices.

After thinking, I am not 100% against a react-loadable compat library but I will not maintain it. Feel free to create another project.

All 10 comments

Hello, yes it is a good idea!

I am playing with this idea:

鈿狅笍 Warning: TypeScript!

See my PR here:
https://github.com/mohsen1/apollo-react-async-ssr/pull/2

I'm getting a weird error when I try it on the server:

Invariant Violation: loadable: SSR requires @loadable/babel-plugin, please install it

is the Babel plugin looking for specific syntax? should the call to loadable() not get abstracted for it to work?

Yes - it's looking for loadable imported from loadable. Then - looking for the import inside it.

@mohsen1 Im getting the same error as @theKashey and it happens when im trying to navigate directly into a loadable route. This not happens if I navigate using the UI of my app.

ok I think this is a bigger task then. The Babel transform should also account for importing the react-loadable Loadable compatibility component from @loadable/component module. It's not too bad though, I might hack on it today.

loadable-components has one implementation - it transforms imports only inside loadable. To solve a problem of this issue all imports has to be transformed.
And thus result of the transformation should be still compatible with the original import - that would solve the problem, letting you pass import from anywhere.

@theKashey can we make it detect import()s inside the parameters of a Loadable component as well?

import { Loadable } from '@loadable/component'

export default Loadable({ loader: () => import('./Component') });

Can you explain what the Babel transform actually does? I am reading the tests but can't exactly follow what's going on

can we make it detect import()s inside the parameters of a Loadable component as well?

Yes, but I dont like this approach. Honestly the current solution is very fragile - for example you could not move loading logic anywhere or wrap it somehow (like with Loadable).

Can you explain what the Babel transform actually does?

It converts import into a "record" with:

  • async import
  • sync (and weak) require
  • cache name
  • and visa versa

50% of that info is used for the clientside loadable, 50% - for the serverside one.

However - sync requires might be removed, and the rest could be added to the import function as a static parameters. Then - you will not need any extra logic to use lodable-components via any compatibility wrapper.

Maybe the complexity does not worth it. Also the API provided by React Loadable is not in the philosophy of React. For example, errors should be handled with Error Boundaries (as React.lazy), so it does not encourages good practices.

After thinking, I am not 100% against a react-loadable compat library but I will not maintain it. Feel free to create another project.

Was this page helpful?
0 / 5 - 0 ratings