https://discord.umbraco.com
Join Discord
v14: workspace contexts and modal dialogs ?
# package-development
k
Just wanted to check this, and i am not doing somethign stuuuupid. I have a workspace element, workspace context, and a workspace view. if i open a modal from the workspace view,
Copy code
ts
const addServerModalContext = this._modalContext?.open(USYNC_PUBLISHSER_ADD_SERVER_MODAL, {
    data: { 
        serverName: name,
        serverUrl: url}
});
then in that modal I don't seem to be able to consume the workspace context ?
Copy code
ts
this.consumeContext(USYNC_PUBLISHER_DASHBOARD_CONTEXT_TOKEN, (_context) => {
   console.log('add server, consumed context');
   this._context = _context;
});
(so it never logs) the consume context does work in the workspace view, so i know i "can" consume the context so , 1. are workspace context's scoped, and because i am opening a modal, i am no longer in the workspace ? 2. have i done something wrong, should i be able to get to the context in the modal ? if its 1. .. can i scope my modal into the workspace ? or do i have to make a global context, for things i want in it and the other workspace ?
---- Obvs i could pass the context when i open the modal ? is that even a sensible thing to do ?
w
I am taking a wild guess. But I reckon it’s scoped to the element in the DOM. so depending where in the DOM tree the modal gets created.
Assume there must be similar patterns in the core.
Wonder if it has to be a global context instead?!
k
Yes I think so too, I might be it has to be global, but I can pass the context and it works 🤷‍♀️
w
Hmm… then I’m outta ideas. One for @Jacob Overgaard or @Niels Lyngsø to comment on how the contexts work
k
I could choose not to do any work in the modal (pass it back) but in this instance there is a check fired to the server so rather it happen in the modal element . It does work passing it, I just want to make sure I am not breaking some patterns
w
Yep I’m a few weeks behind your hacking and exploring. I would imagine what you’re doing is a-okay. But probably best HQ crew chip in and let you know if it’s problematic or not.
n
This works with the routeable modals, But I think you just made me aware that they dont work out of the box with traditional, not routeable, modals. I'm investigating 🙂 I'll be back
w
Follow up question? Should all modals try to be routable?
n
No, not really. A confirm dialog does not make much sense to share with a friend..(Or navigate back to, like if you go back in the browser) But I assume that you would be happy about sharing the 'Infinite editor' for a specific Block of the Block List Editor. — Just as examples. 🙂
The modal, needs a bit of help to make the Context API Work... we might make it more explicit, but for now @Kevin Jump you would need to parse an element to 
originTarget
of the arguments your sending to ModalManagerContext.open(alias/token, args); like this: modalManagerContext.open('my-modal-alias-or-token', {originTarget: this}) // 'this' because I assume you are in a web-component and this is therefor an element. But this really sucks that you have to remember, so I'm not far from changing that into this: modalManagerContext.open(this, 'my-modal-alias-or-token', {other not required args...})
k
Ok, that makes sense 👍
n
Then, the originTarget has to be either the same element as the one you provided the Context from, or a decendant of it. 🙂
(technically the modal sets up a proxy for the context consumption, cause technically a modal is located outside the app (or in the root, sorry i cant remember specifically), so the context api would not have worked if we didnt do something specifically for this use case, but as mentioned above, I think we could make it so you dont have to opt into it)
6 Views
PreviousNext
Powered by

Umbraco

A hub and casual space for you to interact with fellow community members and learn more about Umbraco!

Powered by