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

Initial implementation of a browser extension to add puzzles. #2392

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jpd236
Copy link
Contributor

@jpd236 jpd236 commented Jan 2, 2025

(More details in individual commit messages - this PR is a stack of a few open requests).

See #237

jpd236 added 4 commits January 1, 2025 22:44
When adding a puzzle, we start a transaction to atomically check if a
puzzle already exists with that URL and only add it if either no such
puzzle exists or if the client indicates that duplicate URLs are
allowed. In the event of a transaction failure, we delete the Google
document that was created optimistically before saving the puzzle.

On the client side, we add a new checkbox to allow duplicate URLs,
unchecked by default. If we encounter a duplicate URL error, we show an
error indicating that the puzzle may be a dupe and telling the user what
to check if the duplicate URLs are intentional.
- Propagate user ID to API methods in authenticator
- Add API to list hunts
- Add API to list tags for a hunt (for autocompletion)
- Add API to create a puzzle

Most of the complexity is in the latter. The bulk of the implementation
is shared with the existing flow for creating puzzles, but there is some
jank:

- Wherever we were looking at this.userId, which is populated for Meteor
method execution but not this API path, we need to pass an explicit
userId instead. One pain point is the auto-inferred userId for the
createdBy column of many tables.
- We check the types of the input in both the Meteor method (to take
advantage of the validate scaffolding) as well as the shared logic (so
it's there for API calls).
Allows users to (re)generate and copy-paste a key for external use.
Supports (at least) Chrome and Firefox.

Includes a settings page to input the Jolly Roger instance and API key,
and a popup menu which reads the URL and title from the current page and
provides a form to add it to a particular hunt on that instance. The
form is modeled off of PuzzleModalForm, but condensed vertically to try
to avoid scrolling in the height-limited popup window. We also surface
recently-used tags to make it easier to add multiple puzzles in the same
round/group.

Built as a mostly-independent module in the extension/ folder using npm;
could be split into a separate repository if desired. There is a small
bit of duplication with Jolly Roger proper, but this seems reasonable to
avoid unduly tight coupling and allow using more modern dependencies
than Meteor currently permits.

Uses React Bootstrap and consistent UI components with Jolly Roger, but
is powered by the REST API rather than Meteor, which seems like it would
introduce significant complexity for limited value. Also covered by the
root project's eslint and prettier configs; Typescript checking is
covered by the Webpack compilation. Some checks are disabled because
they require "npm install" to be run from the extension directory. In
general, we probably need to align on an organizational structure before
devoting too much time to making the linters work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant