-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor requests to the API so that they could be computed locally instead #377
Comments
This could look like taking existing calls to So a call like:
Would become something like:
Or with an argument:
We can send the arguments either always as an object, or for one-argument methods we could decide that we don't actually want the wrapping object and generate it inside the implementation if needed. |
I think I forgot to list some of the things the client needs to cover; it needs to cover everything that we use the API URL for. |
This has been fixed now. |
To implement #367, we are going to need to set things up so that sometimes, when you click "Go", instead of making an API request to
/getChunkedData
, we instead call some local JS/WASM code which makes its own web requests and/or operates on local files exposed to the browser, and eventually produces the data needed to render the tube map.To support this, we should refactor the client-side code so that the current code that calls
/getChunkedData
is just one possible implementation of an interface.So, for this issue, we should define a JavaScript
class
to represent that interface, and anotherclass
inheriting from the first that implements it by making requests to the tube map API server. The interface should cover:Then we should replace the existing API code with code to instantiate an instance of this class, and to make API calls through the current implementation of the interface.
The text was updated successfully, but these errors were encountered: