React-Loadable provides you with a component you can use to load a React component later, rather than immediately as you load the React app.
...
For further actions, you may consider blocking this person and/or reporting abuse
It's 2020! Using
react-loadable
, the project completely unmaintained for the past 2 years is a very bad decision.Code splitting is awesome, I totally agree, but there are better ways to use it and better libraries.
I repeat - stop using
react-loadable
.If you don't need SSR - use
React.lazy
, that's all. If you need SSR or looking for more complex solutions - well, there are options.James, many people did put their effort. Have tried to fix
componentWillMount
, tried to fix many other things, ended moving to other projects or forking loadable, cos there were no answers from you, the single maintainer.Having "other priorities in their life" is not an excuse. If you cannot, or don't want to maintain something - you don't have to. However, please make it clear to the ones who are going to use your creation, and don't stop others from not recomending it due to this condition. Especially if they don't have to use it all.
There is a polite way of interaction with your own library users - open the issues, and add "looking for a maintainer" badge. That would be enough to do anything else you value more.
You are very kind and focused on yourself only, as you always have been.
In terms of code splitting I did a lot and contributed enough to the other projects code base, theory and practice. Just not in React-Loadable.
Why? Well, every conversation with you ended like that, and I have other priorities in my life.
And if you are allowing you to have them, then allow anyone else to have the same or the different priorities in their life. Please be a bit more self-reflective.
You know, Has anyone told you how stupid you look up on that high horse?.
I know react universal started as a PR to your project back in the day. It defiantly helped us bootstrap the whole chunk-flushing concept to get SSR and code-splitting to play nice. I believe faceyspacey did some collaboration with you a long time ago & for whatever reason. Ended up its own product, following a wave of other projects pulling the SSR feature back into their projects. All of them today are pretty much still based off the flush-chunks/report mechanism.
I know OSS is tedious and projects come and go, new options pop up and so on. React Loadable still works, but I'm sure someone would have taken over maintainership on your behalf. React loadable gets a ton of active downloads and while it still works - somebody should have stepped up to keep it going for the userbase. Especially with the documentation and everything else. Passionate newbie to OSS could have taken over merging pull requests. If nobody came forward then that's kind of crummy on the OSS community. Checking the repo - it's nice to see all the pull requests merged in, but there were like 300 issues or something which has now been disabled.
I can understand your passion. However, Anton does not represent the worst of open-source by any stretch. His contributions have actually made a difference. Solid code, easy to speak to and get support, nice, long term maintenance, works well with others.
Abandoning users isn't a great move either - I always think twice about installing any of your software because its tough to say you're reliable enough - Yeah its not your problem and if im going to depend on code i should be prepared to maintain it. I'm glad it works still but perhaps "request for maintainers" banner could have helped keep it going... I hand off my old projects, but always care for the users.
For someone who has built a career around OSS - you can come across as a bit of a risk.
Users don't really follow the maintainer. Know what's going on in our lives. Reputation ends up being the thing that follows around. While your software is really good, and you're very talented, interactions with the community have been erratic.
I really don't want to get into some pissing contest. Jamie, it's nice to see you active on GitHub again - reach out to the community when you're tired of a project. You could be the gateway for a bright young engineer to get involved in OSS - might even love it as much as you and you'd have been able to get a maintainer, they'd maybe get a new career direction.
Iβve been there as well, more often than not thatβs how it can turn out. Iβm sorry nobody else stepped up. I really do understand.
Itβs good to see you on github. Youβve dedicated a lot to OSS. Iβm pretty blunt and direct, but when I hammer the point in - i try to not escalate, if that makes sense? When reading past threads hereβs the feeling: βyeah youβre totally right, but how you communicated it made me less inclined to agree. Even though I knew you were completely correctβ - maybe Iβm out of touch but I feel I havenβt seen you pop up much in a while. If youβre getting back in or just doing some cleanup, youβve done great work and I just want to see your points of view and ideas be more well received. Maybe Iβm off base entirely
Just looking to learn here: why is it a very bad decision?
(I wasn't aware of
@loadable/component
when I posted this, but I've since switched my project over and have found no measurable improvement overreact-loadable
)Very bad - because it is competely unmaintained. No real answer was given to any issue, no PR has been merged.
Bad - loadable provides only a simples splitting pattern, if you donβt need SSR itβs better just to use React.lazy, it would work just the same.
Other libraries provide a better SSR support, and, for example, able to split not only components.
Please change this to use @loadable/components as using an unsupported project is bad practice and leads to security issues.
There are other reasons why loadable is better and you can read those in the react official docs
Oh so if that package is transferred to a malicious person and you upgrade a patch or minor version, what happens then?
That's good, but sometimes other projects will be transferred to someone that says they will contribute to it and they will plant malicious code in, similar to what happened with event-stream
I'm not dismissing it, React official docs is. I appreciate the hard work that went into it, but as I said some of the pull requests haven't been merged in over 6 months and it seems to have generally less support.
I personally used it in my projects but as we need to ensure we keep only third party libraries that are strictly supported and maintained I can't use or recommend this one anymore and I feel the blog creator should at least provide a few options to the users that might not have the full picture.
Also, don't be rude. I don't know you and your victimism is uncalled for.
This is very handy for people! The concept of code splitting and lazy loaded components is πππ
However react supports lazy loading out of the box and doesnβt need a third party packages to do this, so my advice would be to stick to the official documented route if possible.
reactjs.org/docs/code-splitting.html
However
Lazy
covers only component level splitting."Other libraries" have already implemented library-level splitting in form of
renderProps
or resource level splitting in form ofhooks
, which let you reduce you bundle size even more.Is lazy loading a component on the page better than having it just be in the initial bundle? For example by using next/dynamic when you have a huge component on the home page is it better to let it be bundled or does making it dynamic have any benefits,does it defer its loading? Could never understand this π