Closed long74100 closed 2 years ago
Love this proposal!
a preliminary search yields 102 results where it is being used in our repos
Definitely commonly used through the platform :) This proposal would save a step/time for engineers.
configurable during instantiation
Would this need to be opt-in, to avoid this being a breaking change for consumers?
Here is a package that uses Axios interceptors to handle the conversions.
Is the idea here to use axios-case-converter
or create our own solution? Either could be valid solutions, just curious which way you might be leaning right now.
I'd also be curious if this would be configured for all requests, or if it could be configured on a per-request basis.
It will have to be opt-in to avoid introducing a breaking change. If axios-case-converter meets all our use-cases (I played with it a little bit and it works), I think we can just leverage it. The per-request basis usage would be dependent on if the consumer is instantiating one client and using it as a singleton. I'm sure we could also support that use case if needed.
Since our backend services are written in Python, our MFEs have to convert API responses to camelCase.
@edx/frontend-platform
exports a util functioncamelCaseObject
for this purpose and a preliminary search yields 102 results where it is being used in our repos. It feels tedious to have to manually convert the casing every time and forgetting to do so could lead to bugs and inconsistencies in the code.It would be beneficial if our http clients in frontend-platform supported automatic case conversions out of the box, configurable during instantiation.
Here is a package that uses Axios interceptors to handle the conversions.
Example of what we have to do today:
Example of what it could look like: