migrate from react-albus to react-step-wizard

[resolritter]

needs more work to be fully fleshed out, but at least the example doesn't break

[zaguiini]

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!

[resolritter]

As react-step-wizard doesn't provide typings by default (jcmcneal/react-step-wizard#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.

[resolritter]

opened jcmcneal/react-step-wizard#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?

[zaguiini]

I'm not sure, to be honest. Doesn't ReactNode works?

[resolritter]

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.

[zaguiini]

Hey @resolritter, please take a look at #39. Thanks!

[zaguiini]

@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?

[resolritter]

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.