You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 17, 2021. It is now read-only.
As part of breaking things apart in #72, I could see us creating a config class that acts as an accessor for other components to read from or set to. Probably similar to HopscotchBubble, each callout or Hopscotch would own its own config class. Or maybe HopscotchBubble creates its own config instance when it's created.
Dunno if there are any utils that are relying on global configs, though. We'll have to explore this more and see what relies on configs and where their configs are coming from. In general, though, does the above sound like it's going in the right direction?
The idea with this approach is that config can inherit from another config. So we will have a hierarchy of configs defaultConfig, globalConfig (hopscotch.configure), tourConfig (tour level options) and calloutConfig(standalone callout options, or specific step options. Inherits from globalConfig if it's a standalone callout).
We still need unit tests for this module, but it's 70% there :)
this sounds like a mess, we should have a consistent interface for setting hopscotch configs at each level
The text was updated successfully, but these errors were encountered: