feat: implement custom map file support #758

achou11 · 2024-09-25T21:13:04Z

~~Stacked on #796~~

Closes #622
Closes #623
Closes #624

Refer to the designs in Figma instead of the screenshots from the issues, since they're a bit outdated.

Implementation details:

~~the error state in the case of validly named file that is actually invalid as a custom map was not detailed in the design, so I had to implement that using my own judgment.~~ EDIT: Mostly eliminated by actually verifying the file (see 5284dc3), although I kept the UI pieces so that we handle the super edge case better in case it really does happen for whatever reason.
for trying it out, you can use fixtures from https://github.com/digidem/styled-map-package/tree/main/test/fixtures

Known issues:

Removing the custom map may not properly update the rendered map (should eventually be fixed in core via fix: support maps that may be removed or replaced in map server plugin comapeo-core#906) - will be resolved before merging. The demo video is using the changes that fix this issue but they're not in the PR yet, so if you're trying to test it yourself locally it probably won't work. EDIT: no longer an issue with b2c015a
Potential loading issue with download icon, causing a visual flicker when initially loading. I'm not sure if this is a dev-only issue but wondering how to fix 🤔

custom-map.mp4

remaining bugs: - modification time not being reliable - map name should not come from file name but from style.json - handle FileSystem.documentDirectory being null?

achou11 · 2024-10-21T18:54:59Z

src/frontend/sharedComponents/icons/index.tsx

+export function DownloadIcon(props: FontIconProps) {
+  return <AntDesignIcon {...props} name="download" />;
+}


The Ant variant was the closest to what the designs had - ideally we would stick with the same icon sets across all icons though...

achou11 · 2024-10-21T19:00:53Z

src/frontend/lib/file-system.ts

 export function convertFileUriToPosixPath(fileUri: string) {
  return fileUri.replace(/^file:\/\//, '');
 }
+
+// TODO: Some overlap with selectFile() from lib/utils but fixes some usage limitations. Ideally use this for everything


just noting this but if there's an interest in unifying the implementations, I'd rather address in a follow up

achou11 · 2024-10-21T19:02:18Z

src/frontend/screens/Settings/MapManagement/CustomMapDetails.tsx

+function LoadingOverlay() {
+  return (
+    <View pointerEvents="none" style={styles.overlay}>
+      <View style={[styles.overlay, {opacity: 0.1, backgroundColor: BLACK}]} />
+      <Loading size={10} />
+    </View>
+  );
+}


could be useful to extract as a shared component, but would prefer to avoid the extra work if not necessary for now

…r occurs

achou11 · 2024-10-21T21:19:38Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+  },
+  importErrorDesciption: {
+    id: 'screens.Settings.MapManagement.BackgroundMaps.importErrorDescription',
+    defaultMessage: 'Unable to import the file. Please go back and try again.',


ideally this should include the name of the file or the map name, but given how the error modal works and the context in which the error occurs, it's a bit tricky to get that to work seamlessly. for now, intentionally settling for just a generalization

achou11 · 2024-10-21T21:20:11Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+        title={
+          selectCustomMapMutation.error || importCustomMapMutation.error
+            ? m.importErrorTitle
+            : undefined
+        }
+        description={
+          selectCustomMapMutation.error || importCustomMapMutation.error
+            ? m.importErrorDesciption
+            : undefined
+        }


we only surface a custom title + description in the case of an import error. otherwise just fallback to the default messaging from the component

achou11 · 2024-10-21T21:20:53Z

src/frontend/sharedTypes/navigation.ts

-  MapSettings: undefined;
-  BackgroundMaps: undefined;
-  BackgroundMapInfo: {
-    bytesStored: number;
-    id: string;
-    styleUrl: string;
-    name: string;
-  };


artifact of Mapeo Mobile

ErikSin

upon looking at this logic for way too long 😬 ... I think i figured out a possible way to seperate the logic to be a little clearer

// BackgroundMaps.tsx

return (
      <ScrollView contentContainerStyle={styles.container}>
        <Text style={styles.aboutText}>{t(m.about)}</Text>
        <View style={styles.descriptionContainer}>
          <Text>{t(m.description1)}</Text>
          <Text>{t(m.description2)}</Text>
        </View>
        { customMapInfoQuery.isFetching ?
             <Loader> : !customMapInfoQuery.data ?
             <ChooseMapFile />:
             <CustomMapDetails/>
        }
        { customMapInfoQuery.isError &&
             <>
                  <Text style={styles.infoLoadErrorText}>
                   {t(m.customMapInfoLoadError)}
                  </Text>
                <Button
                  fullWidth
                  variant="outlined"
                 onPress={() => {
                  removeCustomMapMutation.mutate();
               }}>
                  <Text style={styles.removeMapFileButtonText}>
                     {t(m.removeMapFile)}
                  </Text>
                </Button>
             </>
        }
      </ScrollView>
)

ChooseMapFile could then just deal with its own loading state. But this would require ChooseMapFile to have its own ErrorModal.
And anytime the maps are fetching, the loader is shown. Since the use can only have 1 custom map we don't need to worry about showing the previous map. This would mean that CustomMapDetails would not have to have a loading state, because the parent component is dealing with it

I think this would simplifiy the switch statement with if statements inside of it

ErikSin · 2024-10-21T20:21:59Z

src/backend/src/app.js

 const DB_DIR_NAME = 'sqlite-dbs'
 const CORE_STORAGE_DIR_NAME = 'core-storage'
+const CUSTOM_MAPS_DIR_NAME = 'maps'
+const DEFAULT_CUSTOM_MAP_FILE_NAME = 'default.smp'


Just confirming that this requires the developer to know the names of the directories? If so, that seems quite fragile, maybe something to consider refactoring at the UK retreat.

yeah there's some duplication between frontend and backend in terms of knowing where this directory is. However, there's no good way to share code between the two unless you involve an unnecessary IPC roundtrip, which I'd rather avoid in this case.

for posterity: the way this custom map feature works is the following:

The frontend is responsible for moving a file to and from an app-specific directory on the device. In this case, we the android "document directory" which is something like file:///data/user/0/com.comapeo.dev/files/ and make a maps/default.smp there.

The backend is configured to use the path in (1) as the path to watch for determining if there's a custom map file that can be used for the map server.

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

ErikSin · 2024-10-21T22:12:11Z

src/frontend/hooks/server/maps.ts

+export function useSelectCustomMapFile() {
+  return useMutation({
+    mutationFn: () => {
+      return selectFile({
+        extensionFilters: ['smp'],
+      });
+    },
+  });
+}


I think based on how simple this function is, we should just have a useSelectCustomFile(extenstionfilters?:[string]), and the consuming component can set the extensions. What do you think?

addressed via dcac9e0

Think ideally this stuff in useSelectFileAndImportConfig.ts also lives in the file I created here, but would consider that more of a follow-up item

ErikSin · 2024-10-21T22:30:05Z

src/frontend/hooks/server/maps.ts

+      refresh();
+      queryClient.invalidateQueries({
+        queryKey: [MAPS_QUERY_KEY],
+      });


I don't fully understand the need for the refresh token? From a surface perspective it looks like it is doing the same thing as invalidating the query

yeah the tricky part here is that the invalidation we need is controlled by the consuming map view, not react query. for example:

We have an initial value of: http://localhost:8000/maps/style.json. This is used by the map view, which makes the http request internally to fetch a response. let's say { "name": "my-map" } for the sake of the example.

We do something that should change what style.json we get back in 1 (such as add or remove a map).

We invalidate the query, but that isn't enough in some cases because you can still get the same value of http://localhost:8000/maps/style.json, in which case the mapview won't actually get a new response from that URL because of HTTP caching.

In order to actually force the mapview to fully fetch the response of the same url and ignore the cache, we introduce the refresh token in the form of a url query string, which counts as a new url, even though the query string goes unused by the server that we're calling. we did something similar in Mapeo Mobile for other http resources that would have the same issue (e.g. here)

ErikSin · 2024-10-21T22:47:38Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+      <BottomSheetModal
+        ref={removeMapBottomSheet.sheetRef}
+        isOpen={removeMapBottomSheet.isOpen}>
+        <BottomSheetModalContent
+          icon={<ErrorSvg />}
+          title={t(m.deleteCustomMapTitle)}
+          description={
+            t(m.deleteCustomMapDescription) + '\n\n' + t(m.cannotBeUndone)
+          }
+          buttonConfigs={[
+            {
+              dangerous: true,
+              variation: 'filled',
+              text: t(m.deleteMapButtonText),
+              icon: <MaterialIcon size={30} name="delete" color={WHITE} />,
+              onPress: () => {
+                removeCustomMapMutation.mutate();
+                removeMapBottomSheet.closeSheet();
+              },
+            },


would it not be simpler to have 1 bottom sheet modal, where the contents are conditionally rendered?

in this case i would argue against it for the following reasons:

One is a full-sized sheet and the other isn't. If i remember correctly, we had issues with dynamically switching between full-size and non-full-size (some issue with the component implementation)

It provides a more explicit separation of states that can occur. Part of this is due to a limitation of the how the bottom sheet component is designed, but i'd rather avoid code that does something like isOpen={mapAddedOpen || mapRemovedOpen}, because then there's a greater risk of introducing or seeing the wrong sheet content, unless you're careful about the checks you make in it.

ErikSin · 2024-10-21T22:56:43Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+      if (customMapInfoQuery.isFetching) {
+        renderedMapInfo = customMapInfoQuery.data ? (
+          <CustomMapDetails
+            loading
+            name={customMapInfoQuery.data.name}
+            dateAdded={customMapInfoQuery.data.created}
+            size={customMapInfoQuery.data.size}
+            onRemove={() => {
+              removeMapBottomSheet.openSheet();
+            }}
+          />
+        ) : (
+          <Loading size={10} />
+        );


if its fetching, shouldnt we always be showing a loading state? Under the assumption that there can only be 1 background map, swr doesn't apply here

To clarify: this is handling the case where a map currently exists and we're doing something that would trigger another fetch (e.g. removing or updating).

It is showing a loading state (see the loading prop in the CustomMapDetails) but it's doing a more visually graceful loading state. I found it very jarring for the information to just suddenly disappear, turn into the three dots, and then into some other UI, so I implemented a simple overlay that prevents less layout shift in this specific case.

It looks like this, which may look weird when seeing as a screenshot, but I argue that it's preferable to just showing the dots:

achou11 · 2024-10-22T14:52:58Z

ChooseMapFile could then just deal with its own loading state.

Haven't tried out your suggestion just yet, but I'm a little hesitant about introducing an additional query "boundary" when it may not be necessary to. I usually prefer to keep all of the query logic at the same level and just have the rendered components be pretty dumb.

What I currently like about what I have implemented is that it clearly handles all of the states that this UI can end up in:

Initial load -> show loading
Initial load succeeds, which has the following outcomes:
a. no custom map info -> show upload file UI
b. custom map info exists -> show custom map info
Refetching the custom map info (due to removing the map, but in the future, could be due to updating or adding a map). This has outcomes identical to (2)
An error occurs due to:
a. a bad file being chosen
b. some server error (which is relatively unlikely but could happen)

While the implementation doesn't look pretty, I don't find it overly difficult to follow. Just happens to be a consequence of how to work with react + react query.

Even if I move a lot of the logic to another nested component, I'd still probably end up with the switch statement approach, even though it may be slightly less complicated.

Overall I find it easier to approach building the UI based on react query's status value, even if it results in some duplicated UI code. The data oriented approach feels messy to me because it doesn't guarantee what state the query is in, so you'd have to include specific one-off checks if you go about it that way.

achou11 · 2024-10-22T15:11:04Z

here's a first attempt at what you suggested that takes into the various states that I mentioned (no additional component separation just yet):

 <ScrollView contentContainerStyle={styles.container}>
        <Text style={styles.aboutText}>{t(m.about)}</Text>
        <View style={styles.descriptionContainer}>
          <Text>{t(m.description1)}</Text>
          <Text>{t(m.description2)}</Text>
        </View>

        {/* Think your suggestion was to make this a separate component */}
        {customMapInfoQuery.status === 'pending' ? (
          <Loading size={10} />
        ) : customMapInfoQuery.data ? (
          <CustomMapDetails
            loading={customMapInfoQuery.isFetching}
            name={customMapInfoQuery.data.name}
            dateAdded={customMapInfoQuery.data.created}
            size={customMapInfoQuery.data.size}
            onRemove={() => {
              removeMapBottomSheet.openSheet();
            }}
          />
        ) : customMapInfoQuery.isFetching ? (
          <Loading size={10} />
        ) : (
          <ChooseMapFile
            onChooseFile={() => {
              selectCustomMapMutation.mutate(undefined, {
                onSuccess: asset => {
                  if (!asset) return;

                  importCustomMapMutation.mutate(
                    {
                      uri: asset.uri,
                    },
                    {
                      onError: () => {
                        FileSystem.deleteAsync(asset.uri, {
                          idempotent: true,
                        }).catch(noop);
                      },
                      onSuccess: () => {
                        mapAddedBottomSheet.openSheet();
                      },
                    },
                  );
                },
              });
            }}
          />
        )}

        {customMapInfoQuery.status === 'error' && (
          <>
            <Text style={styles.infoLoadErrorText}>
              {t(m.customMapInfoLoadError)}
            </Text>
            <Button
              fullWidth
              variant="outlined"
              onPress={() => {
                removeCustomMapMutation.mutate();
              }}>
              <Text style={styles.removeMapFileButtonText}>
                {t(m.removeMapFile)}
              </Text>
            </Button>
          </>
        )}
      </ScrollView>

Aside from the error stuff, which I agree can just be inlined as you suggested, I don't know how I feel about this.

EDIT: The more I look at it, the more okay I am with it. Definitely appreciate that it's less code in general. just find it a little harder to understand that ternary, which I could break up into a switch statement or variable in the render body, but that would be closer to the initial criticisim 😄

achou11 · 2024-10-22T15:21:07Z

Alright did a little cleanup that moves towards what you suggested and I'm feeling much better about it:

 <ScrollView contentContainerStyle={styles.container}>
        <Text style={styles.aboutText}>{t(m.about)}</Text>
        <View style={styles.descriptionContainer}>
          <Text>{t(m.description1)}</Text>
          <Text>{t(m.description2)}</Text>
        </View>

        <CustomMapInfoSection
          onChooseFile={() => {
            selectCustomMapMutation.mutate(undefined, {
              onSuccess: asset => {
                if (!asset) return;

                importCustomMapMutation.mutate(
                  {
                    uri: asset.uri,
                  },
                  {
                    onError: () => {
                      FileSystem.deleteAsync(asset.uri, {
                        idempotent: true,
                      }).catch(noop);
                    },
                    onSuccess: () => {
                      mapAddedBottomSheet.openSheet();
                    },
                  },
                );
              },
            });
          }}
          onRemoveMap={() => {
            removeMapBottomSheet.openSheet();
          }}
        />

        {customMapInfoQuery.status === 'error' && (
          <>
            <Text style={styles.infoLoadErrorText}>
              {t(m.customMapInfoLoadError)}
            </Text>
            <Button
              fullWidth
              variant="outlined"
              onPress={() => {
                removeCustomMapMutation.mutate();
              }}>
              <Text style={styles.removeMapFileButtonText}>
                {t(m.removeMapFile)}
              </Text>
            </Button>
          </>
        )}
      </ScrollView>

where CustomMapSection is:

function CustomMapInfoSection({
  onChooseFile,
  onRemoveMap,
}: {
  onChooseFile: () => void;
  onRemoveMap: () => void;
}) {
  const customMapInfoQuery = useGetCustomMapInfo();

  if (customMapInfoQuery.status === 'pending') {
    return <Loading size={10} />;
  }

  if (customMapInfoQuery.data) {
    return (
      <CustomMapDetails
        loading={customMapInfoQuery.isFetching}
        name={customMapInfoQuery.data.name}
        dateAdded={customMapInfoQuery.data.created}
        size={customMapInfoQuery.data.size}
        onRemove={onRemoveMap}
      />
    );
  }

  return customMapInfoQuery.isFetching ? (
    <Loading size={10} />
  ) : (
    <ChooseMapFile onChooseFile={onChooseFile} />
  );
}

Thanks for bearing with me! Now the question is: is this an improvement over what I currently have implemented? Would say that it's maybe enough of an improvement to commit to - thanks for the suggestion and making me think harder about this!

EDIT: Part of me wants to include the error rendering in that CustomMapInfoSection component, but then i think i'll run into some implementation messiness

ErikSin · 2024-10-22T17:13:27Z

Alright did a little cleanup that moves towards what you suggested and I'm feeling much better about it:

 <ScrollView contentContainerStyle={styles.container}>
        <Text style={styles.aboutText}>{t(m.about)}</Text>
        <View style={styles.descriptionContainer}>
          <Text>{t(m.description1)}</Text>
          <Text>{t(m.description2)}</Text>
        </View>

        <CustomMapInfoSection
          onChooseFile={() => {
            selectCustomMapMutation.mutate(undefined, {
              onSuccess: asset => {
                if (!asset) return;

                importCustomMapMutation.mutate(
                  {
                    uri: asset.uri,
                  },
                  {
                    onError: () => {
                      FileSystem.deleteAsync(asset.uri, {
                        idempotent: true,
                      }).catch(noop);
                    },
                    onSuccess: () => {
                      mapAddedBottomSheet.openSheet();
                    },
                  },
                );
              },
            });
          }}
          onRemoveMap={() => {
            removeMapBottomSheet.openSheet();
          }}
        />

        {customMapInfoQuery.status === 'error' && (
          <>
            <Text style={styles.infoLoadErrorText}>
              {t(m.customMapInfoLoadError)}
            </Text>
            <Button
              fullWidth
              variant="outlined"
              onPress={() => {
                removeCustomMapMutation.mutate();
              }}>
              <Text style={styles.removeMapFileButtonText}>
                {t(m.removeMapFile)}
              </Text>
            </Button>
          </>
        )}
      </ScrollView>

where CustomMapSection is:

function CustomMapInfoSection({
  onChooseFile,
  onRemoveMap,
}: {
  onChooseFile: () => void;
  onRemoveMap: () => void;
}) {
  const customMapInfoQuery = useGetCustomMapInfo();

  if (customMapInfoQuery.status === 'pending') {
    return <Loading size={10} />;
  }

  if (customMapInfoQuery.data) {
    return (
      <CustomMapDetails
        loading={customMapInfoQuery.isFetching}
        name={customMapInfoQuery.data.name}
        dateAdded={customMapInfoQuery.data.created}
        size={customMapInfoQuery.data.size}
        onRemove={onRemoveMap}
      />
    );
  }

  return customMapInfoQuery.isFetching ? (
    <Loading size={10} />
  ) : (
    <ChooseMapFile onChooseFile={onChooseFile} />
  );
}

Thanks for bearing with me! Now the question is: is this an improvement over what I currently have implemented? Would say that it's maybe enough of an improvement to commit to - thanks for the suggestion and making me think harder about this!

EDIT: Part of me wants to include the error rendering in that CustomMapInfoSection component, but then i think i'll run into some implementation messiness

This implementation on a surface level looks much cleaner and is defintely easier to follow.

achou11 · 2024-10-22T17:44:54Z

Heads up: I updated core and IPC deps with the fix to the issue mentioned in the PR description via b2c015a

achou11 · 2024-10-22T17:50:16Z

src/backend/package.json

+    "@comapeo/core": "2.0.1",
+    "@comapeo/ipc": "2.0.2",


just highlighting that we need this update to core to fix an issue that happens when removing a custom map.

achou11 · 2024-10-22T17:50:53Z

package.json

@@ -108,14 +108,15 @@
    "tiny-typed-emitter": "^2.1.0",
    "uint8array-extras": "^0.5.0",
    "utm": "^1.1.1",
+    "valibot": "^0.42.1",


I'm introducing this dep for response body validation, which is used when interfacing with the map server

achou11 · 2024-10-22T17:53:27Z

src/backend/src/app.js

 const DB_DIR_NAME = 'sqlite-dbs'
 const CORE_STORAGE_DIR_NAME = 'core-storage'
+const CUSTOM_MAPS_DIR_NAME = 'maps'
+const DEFAULT_CUSTOM_MAP_FILE_NAME = 'default.smp'


for posterity: the way this custom map feature works is the following:

The frontend is responsible for moving a file to and from an app-specific directory on the device. In this case, we the android "document directory" which is something like file:///data/user/0/com.comapeo.dev/files/ and make a maps/default.smp there.

The backend is configured to use the path in (1) as the path to watch for determining if there's a custom map file that can be used for the map server.

ErikSin

Nice job! seems to be working. A few small comments, but non-blocking

ErikSin · 2024-10-23T21:25:27Z

src/frontend/hooks/server/maps.ts

+export function useSelectFile() {
+  return useMutation({
+    mutationFn: (opts: Parameters<typeof selectFile>[0]) => {
+      return selectFile(opts);
+    },
+  });
+}


Do we need this twice?

oh no we don't - i copied this to a different file but forgot to actually use that one. Removed this one via 5a702b4

ErikSin · 2024-10-23T21:37:52Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+                removeCustomMapMutation.mutate();
+                removeMapBottomSheet.closeSheet();


Any concerns about not having a loading state

not super concerned because this happens so quickly and also we have a different modal for an error that may occur. Added a small change anyways just in case though, via b79e78d

ErikSin · 2024-10-23T21:56:32Z

src/frontend/screens/Settings/MapManagement/BackgroundMaps.tsx

+        ref={mapAddedBottomSheet.sheetRef}
+        isOpen={mapAddedBottomSheet.isOpen}>
+        <BottomSheetModalContent
+          icon={<GreenCheckSvg />}


this should have a marginTop of 80

yeah this ideally is fixed in the BottomSheetModalContent component but addressed here as a one-off for now (since we probably do the same in other places). See e65020c

ErikSin · 2024-10-23T22:00:22Z

src/frontend/screens/Settings/MapManagement/index.tsx

+    <ScrollView>
+      <List>
+        <ListItem
+          onPress={() => {
+            navigation.navigate('BackgroundMaps');
+          }}>
+          <ListItemText primary={t(m.backgroundMaps)} />
+        </ListItem>
+      </List>
+    </ScrollView>


This should have a top padding of 40

seems somewhat questionable for that design spec to apply to this page, especially when compared to other settings-like pages.

App settings:

Screen in question (with your suggestion):

My guess is that either:

the app settings page needs to be updated too

the design spec does not apply to pages like these

the app settings page needs to be updated too

ah yeah it this seems likely when looking at the screenshot in #622

I think for the sake of consistency, I'm going to avoid making this change so that it matches the app settings layout. we can address both of those in a follow up (since there are a good number of design changes needed anyways)

achou11 force-pushed the ac/map-management-settings branch 2 times, most recently from ed1ca05 to 43d7b7e Compare September 25, 2024 21:33

achou11 force-pushed the ac/map-management-settings branch from 43d7b7e to 51e88bc Compare October 9, 2024 15:03

achou11 mentioned this pull request Oct 16, 2024

chore: update core and ipc to v2.0.0 #796

Merged

achou11 force-pushed the ac/map-management-settings branch from 51e88bc to 5c26340 Compare October 16, 2024 20:55

achou11 changed the base branch from develop to ac/update-core-2.0.0 October 16, 2024 20:56

Base automatically changed from ac/update-core-2.0.0 to develop October 17, 2024 19:07

achou11 force-pushed the ac/map-management-settings branch from 5c26340 to 632adcc Compare October 17, 2024 19:08

achou11 added 5 commits October 21, 2024 12:09

most of the implementation

7ce39f0

remaining bugs: - modification time not being reliable - map name should not come from file name but from style.json - handle FileSystem.documentDirectory being null?

update implementation to account for core update

b0baa17

force style url reload when removing custom map

44ec0de

loading overlay

ed0f9e4

surface error when map info cannot be loaded

4215dff

achou11 force-pushed the ac/map-management-settings branch from 632adcc to 4215dff Compare October 21, 2024 17:55

more thorough error UI

cd9a5e1

achou11 changed the title ~~WIP: implement offline map file import~~ feat: implement custom map file support Oct 21, 2024

achou11 marked this pull request as ready for review October 21, 2024 18:53

achou11 added 2 commits October 21, 2024 14:56

remove todo comment

3184254

add minor type annotation

0b45968

achou11 commented Oct 21, 2024

View reviewed changes

achou11 requested a review from ErikSin October 21, 2024 19:08

achou11 added 2 commits October 21, 2024 16:35

prevent importing a bad map file

5284dc3

display correct title and description in error modal when import erro…

34976e4

…r occurs

achou11 commented Oct 21, 2024

View reviewed changes

ErikSin requested changes Oct 21, 2024

View reviewed changes

achou11 added 2 commits October 22, 2024 11:28

separate complex part of background maps ui into separate component

1bff26e

make file selection mutation hook more generic

dcac9e0

achou11 requested a review from ErikSin October 22, 2024 15:39

achou11 added 2 commits October 22, 2024 11:41

improve variable name

c0d973e

sort imports

f28d371

achou11 added 2 commits October 22, 2024 13:43

update core and ipc with fix when removing map

b2c015a

Merge branch 'develop' into ac/map-management-settings

89d06e0

remove explicit dep of fastify

3005200

achou11 commented Oct 22, 2024

View reviewed changes

ErikSin approved these changes Oct 23, 2024

View reviewed changes

achou11 added 4 commits October 24, 2024 11:09

actually use shared useSelectFile() hook

5a702b4

add loading state to bottom sheet when removing map

b79e78d

add more top spacing in success bottom sheet

e65020c

remove unused variable

698c819

achou11 merged commit dfd586b into develop Oct 24, 2024
3 checks passed

achou11 deleted the ac/map-management-settings branch October 24, 2024 15:28

		removeCustomMapMutation.mutate();
		removeMapBottomSheet.closeSheet();

feat: implement custom map file support #758

feat: implement custom map file support #758

Conversation

achou11 commented Sep 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ErikSin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

achou11 Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

achou11 Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

achou11 Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

achou11 commented Oct 22, 2024 • edited Loading

achou11 commented Oct 22, 2024 • edited Loading

achou11 commented Oct 22, 2024 • edited Loading

ErikSin commented Oct 22, 2024

achou11 commented Oct 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ErikSin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

achou11 commented Sep 25, 2024 •

edited

Loading

achou11 Oct 22, 2024 •

edited

Loading

achou11 Oct 22, 2024 •

edited

Loading

achou11 Oct 22, 2024 •

edited

Loading

achou11 commented Oct 22, 2024 •

edited

Loading

achou11 commented Oct 22, 2024 •

edited

Loading

achou11 commented Oct 22, 2024 •

edited

Loading