7nohe
feat: add support for new version of @heyapi and use fetch client ins…
@7nohe @seriouslag This is a draft PR that maybe can get some discussion going on how to make this less of a breaking change. The new hey api clients doesn't provide a service anymore by default.
I also noticed that in the main branch the react example the UI doesn't update when you create a new pet, this address this issue as well
might help address this as well: https://github.com/7nohe/openapi-react-query-codegen/issues/94
@seriouslag Also added formatters and linters support, as those would never run on the queries folder but only on the requests folder
Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback
Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback
A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.
Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback
A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.
yes there are several ways to go around this, I was thinking we can discuss it in discord or something so we can align on a way to tackle this with a plan, I don't mind the extra work. An FYI, we might fork this and modify it to our needs as we don't need support for all other clients, only the new fetch, I have published a beta version with these changes to check if it is working in our env and everything seems to be working.
Regardless, i'd much rather contribute to this great lib and not only using a fork, you guys did really nice work here and i'd really want to give back :D
Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback
A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.
yes there are several ways to go around this, I was thinking we can discuss it in discord or something so we can align on a way to tackle this with a plan, I don't mind the extra work. An FYI, we might fork this and modify it to our needs as we don't need support for all other clients, only the new fetch, I have published a beta version with these changes to check if it is working in our env and everything seems to be working.
Regardless, i'd much rather contribute to this great lib and not only using a fork, you guys did really nice work here and i'd really want to give back :D
Thank you for all the work you have put into this! I have been away on vacation and will be for another week. Let’s touch base on discord when I get back.