-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
Es/map server #708
Es/map server #708
Conversation
@gmaclennan I created 2 hooks (technically 1 hook and an API layer) to show the difference in typescript typings. If we do create an API layer, we can control the typing a little easier. And react-query will infer the typings from the api type assertions. If we don't have an API layer, we will need to assert the type to the hook everytime we use it, which gets a little clunky with I know you didn't want to create that extra layer, so I am curious if you think there is a more efficient way of doing this? |
Unfortunately not working as expected. With Also getting a weird error, related to typing a function: Edit:I see now that the second error is becuase i am trying to type a function. But even if I convert it to a |
Indeed, it seems like function overloads are not really supported in JSDoc, which is a shame. I think the best way around this is a manual Verified locally by running:
|
@@ -284,7 +288,7 @@ | |||
"logError": true | |||
}, | |||
"lint-staged": { | |||
"*.{js,ts,tsx}": [ | |||
"*.{js,tsx}": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prettier is not playing well with .d.ts
files. I will look further into this, but I wanted to push this for review while I did that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for posterity, i believe this is an issue with prettier-standard
, see sheerun/prettier-standard#111 (comment). probably not worth trying to fix right now since we're only creating declaration files, but once we do a larger scale migration to TS, we should hopefully have this fixed :)
094f4b4
to
69dbd01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall seems good! had a couple of comments that may require some action. This is just the integration right? i.e. none of the queries/mutations are being used in the PR
package.json
Outdated
@@ -34,10 +34,11 @@ | |||
"start": "electron . --disable-http-cache", | |||
"server": "node index.js --headless", | |||
"dev": "electron . --debug --disable-http-cache", | |||
"postinstall": "npm-run-all -p patch-package extract-presets", | |||
"postinstall": "npm-run-all -p patch-package extract-presets electron-rebuild", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"postinstall": "npm-run-all -p patch-package extract-presets electron-rebuild", | |
"postinstall": "npm-run-all -p patch-package extract-presets rebuild", |
needs to reference the name of the npm script command in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh, that is also why the CI is breaking, I believe!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated: d165cf3
@@ -5,6 +5,7 @@ const { app, dialog, MessageChannelMain, ipcMain } = require('electron') | |||
const isDev = require('electron-is-dev') | |||
const contextMenu = require('electron-context-menu') | |||
const mkdirp = require('mkdirp') | |||
const createMapServer = require('@mapeo/map-server') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we're doing TS checking in this file, would update this import to:
const createMapServer = require('@mapeo/map-server') | |
const createMapServer = require('@mapeo/map-server').default |
That way you get the proper TS annotation (see https://github.com/digidem/mapeo-map-server#usage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yeah that's on the map server side then, we may have removed that functionality for some reason and didn't update the docs. nevermind then! 😄
src/main/index.js
Outdated
// Fortunately map server does not have any expensive functions so it should | ||
// not slow down the main process nor block the render thread if we run it | ||
// here from the main process... | ||
// @ts-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can remove this if you update the import as suggested in the comment above
|
||
export function useMapServerQuery (resourcePath, enabled) { | ||
return useQuery({ | ||
queryKey: [resourcePath], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not super familiar with react query but based on the docs related to query keys, should this be some sort of partitioned array of items based on the path segments of the resourcePath
? For example if we're trying to get a specific style /styles/style-id-1
, we'd have something like queryKey: ['styles', 'style-id-1']
.
Maybe doesn't matter for how we're using it right now, but just curious if that's the more idiomatic approach to the query key
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you are right, I will update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated via: d165cf3
@@ -284,7 +288,7 @@ | |||
"logError": true | |||
}, | |||
"lint-staged": { | |||
"*.{js,ts,tsx}": [ | |||
"*.{js,tsx}": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for posterity, i believe this is an issue with prettier-standard
, see sheerun/prettier-standard#111 (comment). probably not worth trying to fix right now since we're only creating declaration files, but once we do a larger scale migration to TS, we should hopefully have this fixed :)
// @ts-ignore | ||
const MAP_SERVER_URL = 'http://127.0.0.1:' + window.mapServerPort | ||
|
||
export function useMapServerQuery (resourcePath, enabled) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wondering if the idiomatic approach to using react-query is to create a query for each kind of resource. for example instead of the resourcePath
determining what resource we're working with, it could be:
function useGetStylesListQuery(enabled) {
return useQuery(['styles'], ...)
}
function useGetStyleQuery(styleId, enabled) {
return useQuery(['styles', styleId], ...)
}
// etc...
Again, not super familiar with react query best practices but a quick look at the docs seems to lean towards this approach. Guess my reasoning is to make generating the query keys more explicit and easier to understand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, Gregor and I talked a little about this. We were thinking that we did not want to create too many abstractions, given the simplicity of the API. So we decided to just use the one hook, and have the resource path as the keys. I think when we do more complicated things in the future this would be the way to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it, figured it was discussed but asking for my own education whenever i eventually touch this stuff 😄
// @ts-ignore | ||
const MAP_SERVER_URL = 'http://127.0.0.1:' + window.mapServerPort | ||
|
||
export function useMapServerMutation (mutationType, resourcePath) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar question to https://github.com/digidem/mapeo-desktop/pull/708/files#r1050173134 about creating multiple hooks based on resource
d59c2ac
to
c32aa42
Compare
Map Server Integration