Add user tours in Advanced Settings

[bollwyvl]

References

• fixes Build tours in Advanced Settings/overrides.json? #15

Task

• add schema based on Declarative Tours? #2
• add settings machinery
• handle updating/removing tours/menuItems
• add to README
  • features
  • how to build a tour in Advanced Settings
  • how to disable user tours (and the default tours)
• validate on binder
• tests
• upgrade react-joyride to 2.3.0, remove third-party typings
• update use of Placement in steps (where it can also be auto and center)
• script to manage updating the joyride schema when it changes (is currently old)
  • would prefer to do in python 🤷

Follow-on

I started going down the rabbit hole of executing commands based on the signals... would be super fun, but we can easily push that to another PR.

Screens

[fcollonval]

Awesome feature 🚀 ❤️

One quick question, would it make sense to add a second plugin that activates this feature (aka loading the settings and adding the tours to the manager)? The idea behind is for admin to be able to deactivate this feature.

[bollwyvl]

Yeah, that's a good angle.

[bollwyvl]

Split into:

• jupyterlab-tour:plugin, just the manager no tours
• jupyterlab-tour:default-tours, welcome, notebook
• jupyterlab-tour:user-tours, the settings junk

Took some doing, and did theoretically change the top level API, as it changed a number of concrete types to reference interfaces.

[fcollonval]

Thanks a lot @bollwyvl

This is really a nice structure improvement.

For the type changes, it looks that the main change is the use of the interface ITourHandler instead of the concrete type. So this should not bring trouble on downstream extensions, does it?

Let me know when you are ready with this one.

[bollwyvl]

Cool, thanks for the review. Looks like i gotta fix some tests, which is fine, though I'll have to mock settingsmanager, probably, as it's not exactly a lightweight chain.

I don't think the Handler -> IHandler is going to break anybody's stuff. I can actually probably revert those signature changes, if the manager/handler stuff stays in core, but it semi-dirtily references the WELCOME_ID. However, I think they are good from an API contract point of view. Also, I strongly feel that the user-focused thing should be enabled by default, but that could be surprising to a current deployer. In light of both of these, I think a 4.0 is probably going to be warranted, but certainly a 3.1.

I ran into some issues with generating the schema, and can't find my hacked script... will try a little bit more this weekend.

[bollwyvl]

I think i am going to extract most of the changes to ITourManager out to IUserTourManager... though firing off the tests with what's in might be good to make sure i didn't mess up the tests too much...

[bollwyvl]

Yep, pretty happy with the new shape: it removes some weird timing things, etc.

[bollwyvl]

@fcollonval no more changes planned from this side, but happy to address any comments!

[fcollonval]

Thanks @bollwyvl

I have two minor comments. Then we are good to go.

[fcollonval]

What about adding the alternative with the command line. Something like

---

Alternatively, you can also use the following commands:

jupyter labextension disable "jupyterlab-tour:user-tours"
jupyter labextension disable "jupyterlab-tour:default-tours"

To enable the extension, use jupyter labextension enable ....

[bollwyvl]

good call, 66b0f95

[bollwyvl]

@fcollonval thanks, added both ideas.

[fcollonval]

Thanks again for this great feature and the quick reply to the review.

[bollwyvl]

boo test fail, looking...

[bollwyvl]

fix from cefa2d7 passes locally 🎉

[bollwyvl]

Cool, thanks for the merge. No hurry on release, as we have a bunch of plumbing on lite to do before being able to use it, but I'll subscribe to releases... And no doubt have to make some issues. Some things while tooling through the code base: - automating joyride types to schema. Maybe there's a way to write some subclasses that will hide the tricky parts - specifying lab commands to run when various events. This has been very helpful on jupyterlab-starters, and would give JSON workflows a little more power. - markdown. Being able to opt into some markdown (which might include commandlinker links) for the step bodies would open a lot of opportunities - xpath. The css selectors fall down on finding some lab things. I'd love if selectors starting with / were interpreted as xpath selectors, seems like a light transform. These last three kinda quack like "middleware," which could be registered by plugins and opted into in a tour definition in the settings/command API... As these would not be part of the official types, they'd need a new place in the schema, e.g. "extras" or "transformers," e.g. {"markdown": true, "xpath": true, "commands": true} at the simplest, though they might need configuration...