Client refactor #85
Draft
Client refactor #85
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…y for easier organization This will also be useful for starting work with chaining methods in RPC
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
…hod chaining (WIP)
…t only works with promises (to be fixed)
…ng errors in provided handler, added some tests
…then) on given chain of methods
…or method catcher, added client test
…al modules, either given as dynamic or static import)
… returning dynamic import This should allow proper type definitions in module option of client when provided a partial module
…rt partial modules This is useful when part of a module is available client-side and a call can be made synchronously. Now, type definitions can optionally reflect when that module is available and avoid wrapping the return result in a Promise. The default remains the same, and the Module type parameter goes through transformations to reflect the transport of function data from a remote location (wrapping it in a Promise and adding support for HTML forms). Currently, the client needs this type parameter passed explicitly (passing partial module to `.module` option alone isn't enough but I'm unsure how to work around that).
…adding tests for types Also added more options for PromisifiedModule type (types still need to be reorganized and thought out)
…terfaces (being utilized in rewritten client)
…ot full support but useful for supporting them) Iterator methods and properties given on the client can now be intercepted to potentially support generators. This would need support from both the server and client to return and transform into async generators from the server.
…ck old client tests, accidentally deleted)
…tests too (I won't even pretend to understand this one) Previously type tests stalled forever and typedoc generation failed, now it doesn't. I'm not sure which upgrade actually fixed the problem but I won't complain.
Build time for typedocs are incredibly slow and type tests are also slow but they do seem to work locally (unsure of what impact on types in IDE will be)
…ions, optimized MergeMethods type
These should be much easier to work with in the new client. The old client's utilities have been updated to make use of the new utilities in the meantime (and those temporary, old functions have been marked deprecated).
…enamed some functions
…s, experimenting with new "resolvers" for RPC
…during internal usage (to reflect defaults)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of the 1.0 release, the code should be easier to read, debug, and contribute. As part of this refactor, I also plan to consider what method chaining looks like in the library for the future. While this PR does not include method chaining, it should include changes that make it possible.
Changes:
New features (non-breaking):
Moduletype) optionalBreaking changes (and new features):
options.moduletypes with providedModuleTypetype parameterModuleTypeis not provided or when both type parameters are provided. When only theModuleTypeis provided (as in previous version), behavior remains the same.options.modulewill only be reflected if options type is also provided as a generic, otherwiseModuleTypewill be utilized (as expected)as constso type parameter can pick up on selected optionsoptions.postRequestnow takes three arguments:(args, result, name) => unknown(args have been added)