Skip to content
This repository has been archived by the owner on Sep 10, 2022. It is now read-only.

Roadmap #348

Closed
7 of 10 tasks
TrySound opened this issue Apr 10, 2017 · 19 comments
Closed
7 of 10 tasks

Roadmap #348

TrySound opened this issue Apr 10, 2017 · 19 comments

Comments

@TrySound
Copy link
Contributor

TrySound commented Apr 10, 2017

Let's take some wishes for major release. Here's my thoughts.

  • es modules bundle entry point
  • commonjs bundle entry point
  • remove per file hoc support (to prevent babel helpers duplicating). Tree shaking will help with bundles
  • rewrite this section (optimizing-bundle-size) with note about tree shaking
  • add flow typings
  • add typescript typings
  • document patterns for using Recompose inside component modules (Document patterns for using Recompose inside component modules #153)
  • remove fbjs dependency caz single line utility shouldn't pull 2mb of dependencies
  • reduce babel config for node
  • consider to change code style
@istarkov istarkov mentioned this issue Apr 10, 2017
@timkindberg
Copy link
Contributor

I think #299 is very needed.

@timkindberg
Copy link
Contributor

I also think #321 is a no-brainer for a core higher order component.

I feel the reason it got closed is not good enough, it should be reopened. We can add it now and deal with future stuff in the future.

@timkindberg
Copy link
Contributor

So I added a complete PR #357 that satisfies #321. I hope its good enough for next release.

@rnicholus
Copy link

Is this the roadmap for v1.0? If not, I'm curious what is needed to release a 1.0 version of this library.

@istarkov
Copy link
Contributor

@rnicholus no it's wishes of @TrySound and all the progressive humanity :-) BTW I think their are close to the part of real roadmap.
I assume that real roadmap also contains documentation, react fiber fixes, and deprecations of some rarely used enhancers.

@Panoplos
Copy link

Panoplos commented Apr 27, 2017

  • Provide option in Relay helper package to support Relay Modern. ;^)

@threehams
Copy link

One issue with including typings in the library is that you'll need many more major version updates than normal, as improvements in Typescript or Flow results in narrowing definitions over time (which causes breaking changes).

It's nice to make them official, but there's a tradeoff there.

@Andarist
Copy link
Contributor

remove per file hoc support (to prevent babel helpers duplicating). Tree shaking will help with bundles

it wont help commonjs consumers though if you remove per file hoc support, it will mean they need to go all in with recompose when importing even a single HOC

@clayne11
Copy link

clayne11 commented Jul 28, 2017

I've found some massive holes in the current @types/recompose typings that I've implemented fixes for. Do you want me to a submit a PR with updated, improved types here?

@istarkov
Copy link
Contributor

what is @types/recompose?

@threehams
Copy link

That's generated from the recompose folder on DefinitelyTyped. You'll want to submit the PR there.

@clayne11
Copy link

I realize that those types are from DefinitelyTyped, but the very first post in this thread talks about bringing Typescript typings into the repo. I'm offering to do just that through a PR. Are you guys open to a PR for that? It's definitely better to have the types directly in the repo than in DefinitelyTyped IMO.

@istarkov
Copy link
Contributor

For flow we have libdef internally and we copy it into flow-typed repo, every time something has changed.
I dont like current behaviour but see no other way now. I think it will be possible somehow provide libdefinitions without copying.
I have zero knowledge about ts, and all the infrastructure around. If it will be done like current flow support - with tests and example we will accept such PR

@clayne11
Copy link

clayne11 commented Jul 29, 2017

With Typescript, you can simply include the types in the library and import them automatically along with the library. You don't have to copy them anywhere, simply publish them to NPM. If I have time I'll make a PR that brings in the types.

Over the last couple of days I've fleshed out a lot of the types for the library and the only ones that don't work great are due to limitations in the Typescript language itself.

@TrySound
Copy link
Contributor Author

@istarkov Why you add it locally? You can just keep it in flow-typed repo without copying.

@istarkov
Copy link
Contributor

To make sure that we have some kind of controlled libdef. As I dont like the idea that everyone in flowtyped repo can change your definitions.

@TrySound
Copy link
Contributor Author

Everyone still can and will. But you should take those changes and add to this repo. Are you fan of two way data binding?:)

@istarkov
Copy link
Contributor

I'm pretty sure that current flowtyped repo is some kind of intermediate step forward. And will be deprecated in near future. Until that time I can accept current pain.

@skrivle
Copy link

skrivle commented Sep 5, 2017

I believe it's possible to add an index.flow.js file where you put the types, this would avoid the copy/paste hassle. Apollo client handles it this way https://github.com/apollographql/apollo-client/tree/master/src

@TrySound TrySound closed this as completed May 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants