react-recompose - moving forward

[brodybits]

General vision & goals (added post-2022):

open for feedback & discussion

• maintain consistency with existing recompose ecosphere such as:
  • @types/recompose
  • http://stackoverflow.com/questions/tagged/recompose
  • https://github.com/suguru03/recomposer - looks like a nice higher-level TypeScript wrapper
• maintain consistency with other forks us much as possible to make it easier to share & merge updates, Change withContext & getContext to use new context API #43 for example
• keep dependencies updated as much as possible
• test & support with ecosphere, for example:
  • Node.js updates
  • React 18
  • Preact
• encourage new functionality to be published in separate modules, in the interest of "small focused modules" as I said in issue RFC: small focused modules #30

Even with the original recompose project frozen dead, I would like to maintain consistency as much as possible or practical. I think the most important things in this fork is to keep a modernized and supported version of recompose that continues working within its ever-changing ecosphere.

---

• use GitHub action for CI testing
• automate testing of dist & release JavaScript builds
• update devDependencies to (hopefully) resolve remaining dev security audit issues ref:
  • node-fetch vulnerability issue (denial of service) acdlite/recompose#817
  • fbjs dependency still present in lock file acdlite/recompose#825
• support newer React context API - PR Change withContext & getContext to use new context API #43 ref:
  • PR: Change withContext and getContext to use new context API acdlite/recompose#775
  • issue: Any plans for the new context API? acdlite/recompose#609
• update hoist-non-react-statics to support newer React features, with known size increase as proposed in:
  • Fix hoistStatics hoisting statics of react ^16.3 features acdlite/recompose#763
  • PR feat: update hoist-non-react-statics -> 3 (...) #36
• improve integration with newer RxJS versions ref: new version rxjs do not work for recompose acdlite/recompose#748
• continue modernizing this fork of recompose ref: Start to modernize recompose (...) acdlite/recompose#826

Referencing discussions for context:

• Why recommend Hooks API? acdlite/recompose#756
• Forked, Updated, and Published  acdlite/recompose#819
• Suggest alternative to branch(), renderComponent(), renderNothing(), compose(), etc acdlite/recompose#828

---

More TODO items post-2022:

• test with Preact & React 18
• improve CI testing with React 18 & Preact - testing beyond React 17 - consider replacing enzyme #40, improve Preact testing & documentation #41
• look into replacing enzyme which seems to be eol now ref: testing beyond React 17 - consider replacing enzyme #40
• sort out lifecycle method warnings - it would be ideal to avoid using unsafe lifecycle methods, if possible without breaking anything working on Preact (not sure about continuing support for React pre-16.3)
• :consider CI testing with React pre-16
• update peerDependencies in src/packages/recompose/package.json to drop support for React pre-16.3 & drop testing with React 16.2 - prerequisite for PR Change withContext & getContext to use new context API #43
• improve CI dist build testing in .github/workflows - improve CI build testing #42
• evaluate https://github.com/sanity-io/react-props-stream vs existing recompose stream functionality
• I think build:recompose vs release build is not clear enough: it looks like release build script includes both individual module Babel build & rollup while build:recompose includes only rollup

[daleyjem]

@brodybits Thank you for your work. My team still uses recompose and have been doing aliasing here and there to go from it to the @Hypnosphi version... and now exploring using this one.

Just my thoughts looking into this repo:

• If recompose-relay is losing support (which is fine with me), might it make sense to drop its code, and stop operating like a monorepo (move everything to the root)?
• I'd personally hope that making this fork more enticing to consumers would be prioritized over some of the more administrative (CI, Node versions, etc.) type stuff. Those are definitely important for contributors, but consumers might be dissuaded for a few reasons.
  • Getting @types/react-recompose up, without the npm:... aliasing requirement would feel much better. It's the one sore thumb in list of non-aliased deps. Could you copy/pasta from here until a more elegant solution is feasible?
  • Mentioning this is a fork is certainly fine, but the main README feels a bit neglected. A number of @acdlite links are still in there and make it seem like another temporary fork.

[brodybits]

@daleyjem thanks for your feedback and interest!

I think all of your points make sense in terms of usability.

I am not yet convinced of a few things, and I have added a "general vision" section to the description to help address some of these items.

I would like to further investigate the unsupported recompose-relay & types/flow-example sub-packages before completely removing them. And reorganizing the source may make it harder to share improvements between the various forks, with potential risk of losing consistency with the original version.

My rationale for prioritizing the CI improvements has been to keep the builds as well tested as possible, to avoid potential breakage in the future. And I would like to avoid outdated dependencies as much as possible to avoid potential security issues and other possible breakage in the future.

Documentation could certainly use some improvement, just raised & pinned #44 (with help wanted).

By "Getting @types/react-recompose up", I am not sure whether you meant submitting a react-recompose entry to the DefinitelyTyped project or just copying the recompose DTD into this project. Assuming you meant copying the DTD into this project, it makes total sense but comes with a few caveats:

• may need some more work with the release build script
• I would prefer not to add this without some testing.

If you would like me to prioritize some of these usability improvements, it would be really helpful if you could give me some kind of an idea what kind of a project you have and how you are using this package. If you would rather discuss this by private email, please contact: chris.brody@gmail.com

[daleyjem]

@brodybits I can't say I'm 100% sure what I myself mean by "Getting @types/react-recompose up" 😝
I guess whichever is the best way to not have to alias because of types. I'm willing to help if you've got something started already... or I can look into it more. Admittedly, my DTD file knowledge isn't fantastic though.