any future plans?

[plandem]

Hi again. Long time.

about 8 months ago, I did draft based on ideas from issues here. It would be nice to have something like this, actually. Can you review it?!

https://github.com/plandem/react-redux-controller/tree/v2

[damassi]

Hi @plandem - Thanks for the update! We're still using RRC internally and it's working well, but have been increasingly moving towards TypeScript which makes some of the abstractions in this library difficult to resolve in a simple / conventional fashion. That said, what you have looks really nice :) (One thing to note, however, is that the decorators spec is still stuck in Stage II, and might not go forward.)

[plandem]

decorators are supported by typescript. what’s the problem with TS, btw?! And decorators at my v2 is just a another way, you still can use it without decorators.

Sent from iPhone

On Feb 9, 2018, at 12:21, Christopher Pappas notifications@github.com wrote:

Hi @plandem - Thanks for the update! We're still using RRC internally and it's working well, but have been increasingly moving towards TypeScript which makes some of the abstractions in this library difficult to resolve in a simple / conventional fashion. That said, what you have looks really nice :) (One thing to note, however, is that the decorators spec is still stuck in Stage II, and might not go forward.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[damassi]

TypeScript does support them, but the more important thing to consider is TC39, which TypeScript is building upon. If they choose to not go forward and advance them past Stage II, then TypeScript will be left with a fork of JavaScript which goes against a lot of the founding principles. Check out this thread for a few scant details. I love decorates and wish they would just settle the differences and advance them!

Re TypeScript + RRC, the normal interface-based approach for typing components consists of this form:

interface Props {
  name: string
}

class Title extends Component<Props> {
  ...
}

// or

const Title: SFC<Props> = (props) => {
  ...
})

But unfortunately with context its not this easy, leading to the need to break conventions.

The argument could be said that RRC's typed selectors are sufficient, but intellisense and auto-complete are too useful to ignore.

[plandem]

sorry, still can't get your point about TS. You can use it like this:

class Title extends Component<any, Props> {
  ...
}

[damassi]

Context values extracted from RRC don't come through as props, and the second interface parameter is for state.

[plandem]

you are right about second interface, never used tsx before. Well, RRC still can be a pure JS :)

[acjay]

I've often thought it would probably be better to use https://github.com/acdlite/recompose/blob/master/docs/API.md#withcontext (or something like it) to inject data as props. Perhaps that would help.

But to chime in on the original question, @plandem, I recommend making this your own if you like the overall approach. I've also been pointing people at Freactal, which seems to have developed along a similar philosophy, but definitely has a bigger following. Although I'd love to make a V2 of RRC, or even just make incremental improvements on the current version, I'd say it's probably not likely. So it's up to whomever has the time and inclination to run with it 😄

I'll close this and edit the README to reflect that it's not being actively worked on.

[plandem]

@acjay sadly, Freactal requires much more effort to integrate and code is not so nice/clear as with RRC. I would like to see development of RRC - of course I can create own repository, but RRC name fits so nicely :(

P.S.: about recompose + withContext, good idea, need to investigate.