How can we refactor how modals work so that plugins can provide their own modals? #1112
Unanswered
cjthompson
asked this question in
Q&A
Replies: 1 comment 2 replies
-
While not react specific, I would take a look at the plug-and-play package as it's the defacto standard for implementing a plugin system. Then after that, looking into Nest.js and other frameworks that have implemented plugins to any degree would provide food for thought. With that in mind, since auto-loading of plugins is desired, updating the codebase to use Nest.js may be beneficial as there is a bunch of additional functionality the framework would end up providing. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Overview
Currently, there is a local ModalProvider that can render a few specific modals, like Send or Receive.
As we move into our plugin model, we want plugins to be able to support rendering modals without the need to touch any code outside of the
src/plugins
directoryThis is a research spike looking for suggestions from React experts on how we should refactor our code to allow for arbitrary modals to be shown.
Reference
See
src/context/ModalProvider/ModalProvider.tsx
for how theuseModal
hook worksSee
src/components/AssetHeader/AssetActions.tsx
for howuseModal
is currently used to show a Send and Receive modalSee
src/plugins/index.tsx
andsrc/plugins/cosmos/index.tsx
for how plugins work. This plugin registration feature could be expanded to include registering modals in some way?Questions to answer:
src/plugins
src/plugins
can cause a modal to be open or closedExample: The Cosmos Plugin needs to be able to render it's own Send modal and not the current global Send modal.
Beta Was this translation helpful? Give feedback.
All reactions