Skip to content
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

Merged
merged 33 commits into from
Jan 19, 2023
Merged

Es/map server #708

merged 33 commits into from
Jan 19, 2023

Conversation

ErikSin
Copy link
Contributor

@ErikSin ErikSin commented Nov 28, 2022

Map Server Integration

@ErikSin
Copy link
Contributor Author

ErikSin commented Nov 28, 2022

@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 tanstack typings.

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?

@gmaclennan
Copy link
Member

@ErikSin see my commit 70fad5f for an example of how you might do this.

@ErikSin
Copy link
Contributor Author

ErikSin commented Nov 29, 2022

@ErikSin see my commit 70fad5f for an example of how you might do this.

Unfortunately not working as expected. With styles/${string} I should be expecting a styleJson. But I am still getting a MapServerStyleInfo

image

Also getting a weird error, related to typing a function:
image

image

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 const im still getting errors:

image

@gmaclennan
Copy link
Member

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 d.ts file for the hook. I've pushed an example to a separate branch: 53ac077

Verified locally by running:

❯ ./node_modules/.bin/tsc --noEmit --allowJs --esModuleInterop --jsx react src/renderer/hooks/MapServerExample.js

@ErikSin ErikSin marked this pull request as ready for review December 7, 2022 02:43
@@ -284,7 +288,7 @@
"logError": true
},
"lint-staged": {
"*.{js,ts,tsx}": [
"*.{js,tsx}": [
Copy link
Contributor Author

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

Copy link
Member

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 :)

Copy link
Member

@achou11 achou11 left a 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",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"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

Copy link
Contributor Author

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!

Copy link
Contributor Author

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')
Copy link
Member

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:

Suggested change
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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure why, but adding .default just breaks the app.
image

Copy link
Member

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! 😄

// 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
Copy link
Member

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],
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated via: d165cf3

src/renderer/hooks/useMapServerQuery.js Outdated Show resolved Hide resolved
src/renderer/hooks/useMapServerMutation.js Outdated Show resolved Hide resolved
@@ -284,7 +288,7 @@
"logError": true
},
"lint-staged": {
"*.{js,ts,tsx}": [
"*.{js,tsx}": [
Copy link
Member

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) {
Copy link
Member

@achou11 achou11 Dec 15, 2022

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

Copy link
Contributor Author

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.

Copy link
Member

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) {
Copy link
Member

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

@ErikSin ErikSin merged commit c989c41 into master Jan 19, 2023
@ErikSin ErikSin deleted the es/map-server branch January 19, 2023 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants