Open resolritter opened 4 years ago
Thanks for the PR! In the last few weeks, I'm working on a newer version of the library that accepts not only different wizard components but form libraries as well. This PR could help me achieve that. So far the "v2" is private but as soon as it's public I'll copy the contents of this PR and give you full credit.
Please don't stop working on this one as this will be useful! Thanks once again!
As react-step-wizard
doesn't provide typings by default (https://github.com/jcmcneal/react-step-wizard/issues/31), I've added some here. I'll probably be using them throughout this week in a project and observing how it plays out.
I've also made some changes to src/types.ts
to make them nicer.
opened https://github.com/jcmcneal/react-step-wizard/pull/70 for having the types in react-step-wizard
itself.
I had to look into this repo's exports to figure out I should export React Node types as JSX.Element. @zaguiini do you know why?
I'm not sure, to be honest. Doesn't ReactNode
works?
I'm not sure, to be honest. Doesn't
ReactNode
works?
I've tried all weird combinations of importing syntaxes and declarations, but re-exporting the type from the React namespace didn't work. FWIW the MR I put up on react-step-wizard
got accepted, so it'll be possible to deprecate the typings I've baked into this MR (at src/@types/react-step-wizard.d.ts
). No harm in keeping it around for a while, though.
Hey @resolritter, please take a look at https://github.com/zaguiini/formik-wizard/issues/39. Thanks!
@resolritter, any updates? I'd like to incorporate the react-step-wizard
adapter into react-final-wizard
. Looks promising to have competition for react-albus
as a wizard adapter. Have you had time to read #39?
I am not currently active on front-end library projects for a while. Not that I dislike them, rather I have some other priorities right now.
Regarding #39 's direction, I don't know what'd be the action for me to take there. My gut feeling about reading it is that if you try to wrap everything, you'll only end up reaching the lowest common denominator. That would not lead to the optimal outcome because users wouldn't be able to leverage the underlying library's details. As an example, react-step-wizard
supports transitions while react-albus
doesn't... How would you deal with that?
I made this PR not because react-step-wizard
is better or worse, but primarily because it's maintained and has some features which react-albus
doesn't have. I'm not sure what would take to support both without hindering the consumer... Maybe extend the APIs as far as possible to cover both, then feature-gate some parts of it depending on the back-end chosen? I don't know.
I'm looking at the code in https://github.com/zaguiini/formik-wizard/blob/master/src/index.tsx and noticing that the part react-albus
influences is quite small - noticeably, this PR's changes are quite small as well. Maybe there's some opportunity to extract as much code as possible into a common "core" module and have separate packages (as in, separate implementations for each library) which use as much of the core as possible. Since they'd not be wrapped by an adapter or anything like that, it'd mean you have to work on two (or N) different code bases for each library. Honestly, I don't know which approach is better because I'm out of my depth when it comes to creating libraries like this one.
Finally, in response to your call for action, I don't know what you're expecting of me.
needs more work to be fully fleshed out, but at least the example doesn't break