Control currently visible GitHub repo via URL

[sebmos]

Currently, the visible GitHub repo is stored in some browser storage, which makes it hard to have different repos open in different windows. It would be great if this info, possibly also the layer currently being edited, came from the URL instead.

[nickcoutsos]

Hmm, I hadn't actually considered working on multiple keymaps simultaneously... could you tell me a little more about your workflow and how it's being impacted? The last-picked repo/branch/keyboard is loaded from local storage on load (or when switching to the GitHub source if not already active), so if you do something like

1. Open app in tab A
2. Pick a repo/branch/keyboard
3. Open app in tab B
4. Pick another repo/branch/keyboard
5. Reload app in tab A (keyboard from tab B is active)

This much is expected, but I don't know if there's any side effects like the tab's selected keyboard changing while attempting to save changes.

I do still see the advantage of having URL-based selection, but it gets hairy. One of the reasons I don't have it already is that it's not just the repository selection that identifies it so the full path would be something like /<repo>/<branch>/<keyboard>/layers/<layerIndex>.

As an alternative, something I'd been thinking about is replacing the source selection with a flat list of keyboards that can each individually attached to a GitHub, FileSystem, or raw text. That'd be some work, though.

[sebmos]

1. Open app in tab A
2. Pick a repo/branch/keyboard
3. Open app in tab B
4. Pick another repo/branch/keyboard
5. Reload app in tab A (keyboard from tab B is active)

That’s it, yes. The reason for refreshing is that these tabs stay open for a long time, and sometimes I want to refresh them because I’ve made a change on a different computer I want to pick up before continuing editing.

[…] something like /<repo>/<branch>/<keyboard>/layers/<layerIndex>.

I don’t see much of a downside to a path like that!

[nickcoutsos]

The reason for refreshing is that these tabs stay open for a long time, and sometimes I want to refresh them because I’ve made a change on a different computer I want to pick up before continuing editing.

This should be possible now without reloading the page. Next to the Save button there's refresh/reload button (that I'm now realizing lacks a tooltip) that will trigger a refresh of in-memory data with the latest in the GitHub repo.

[sebmos]

Hm, I guess that works and I've used it once since you mentioned it, but on balance I'd still prefer being able to do this using "native" browser features. The line of where state should be persisted (and what should be persisted at all) can be blurry in modern web apps, but I would argue that the repo you're looking at (and the specific page/layer you're on) is navigational state that fits quite well with being in the URL. I can't really think of any downsides (aside from the time it would take to male the change, of course).