-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat(sandbox,lib,demo): modal in portal #416
feat(sandbox,lib,demo): modal in portal #416
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Is it worth making a break change and bump the major version? I wouldn't do that until we have real major improvements. It can give false impression to users. |
I was contemplating whether we should pass |
What do you think, @demetriusfeijoo, @Dawntraoz, @BibiSebi, @eunjae-lee? Major or minor version? |
Hey @johannes-lindgren, sorry for the late reply. I think we could go as you said, but just release a minor version and update our starters/templates to include Then, In the future, if a new feature introduces an unavoidable breaking change, we can enjoy the opportunity and make the enablePortalModal prop always true by default in the SDK. 🤔 |
With a non-breaking change, how do we push users to upgrade? If the release is minor, users are going to increase the version to the latest and call it a day. |
As it is not a breaking change I would stick with minor. What we can think about is to share this change in our discord. Or even think about opening up discussions (https://github.com/storyblok/field-plugin/discussions/landing) to announce these changes. I would not force them. If they encounter the issue, they will search for answers in our docs/community channels anyway). |
I think the users are more likely to catch this bug, and they will report it via helpdesk. |
@demetriusfeijoo, @BibiSebi, @Dawntraoz, I added an option to @BibiSebi, is it okay to update the templates like this in this PR? They are fetched from GitHub right? It it fetched with a tag? I mean, if we upgrade the core library, do we need to release a new version of the CLI as well? Once this is released, we will need to upgrade all of Storyblok's field plugins that uses modals. I suppose not all of them have been migrated to the new SDK, for example, the table and annotated image plugins? These are the ones I can think of:
Did I miss some? |
Hey @johannes-lindgren 🙌 I started reviewing it but didn't manage to finish it yet.
Oh, I didn't know about |
After reviewing the changes on Storyfront, I see that major version indeed might be a better solution here. Let's go with that but let's discuss before hand if we want to somehow add a changelog or a new section to the readme explaining the breaking change? Also we need to update our docs with the new option. |
@BibiSebi, @demetriusfeijoo, @Dawntraoz; should I revert my recent changes that introduced the option? Or should I simply merge this as-is, and then follow up with a separate PR that makes this option the default? |
I know that Bynder doesn't have continuous deployment set up, but do the e-commerce plugins have that? Also, have we upgraded all the old e-commerce plugins yet? |
@johannes-lindgren @BibiSebi @demetriusfeijoo After reading the discussions, these are my 2 cents: Johannes, can you include the option in the README.md or docs so it is already documented? In that case, I would then merge as-is, release a major version for For the CD on e-commerce plugins, maybe @demetriusfeijoo can answer surely, but as far as I can see in the repo field-plugin e-commerce, all of them have, but they're still some missing in that repo 🤔 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @johannes-lindgren 🙌
@BibiSebi, @demetriusfeijoo, @Dawntraoz; should I revert my recent changes that introduced the option? Or should I simply merge this as-is, and then follow up with a separate PR that makes this option the default?
I think it could be done in a separate PR 👍
I know that Bynder doesn't have continuous deployment set up, but do the e-commerce plugins have that?
All the e-commerce integrations in the main branch have continuous deployment
Also, have we upgraded all the old e-commerce plugins yet?
Not yet 😢
As Alba mentioned there was one TS error related to the new added option:
I have left a comment about the tests which I think may be wrong but overall, the change looks good to me. 👏 👏
describe('enablePortalModal', () => { | ||
it('is optional', () => { | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: undefined, | ||
}), | ||
).toEqual(true) | ||
}) | ||
it('is a boolean', () => { | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: true, | ||
}), | ||
).toEqual(true) | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: false, | ||
}), | ||
).toEqual(true) | ||
const { subscribeState: _subscribeState, ...subWithoutSubscribeState } = | ||
stub | ||
expect(isPluginLoadedMessage(subWithoutSubscribeState)).toEqual(true) | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: 'false', | ||
}), | ||
).toEqual(false) | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: 123, | ||
}), | ||
).toEqual(false) | ||
expect( | ||
isPluginLoadedMessage({ | ||
...stub, | ||
subscribeState: null, | ||
}), | ||
).toEqual(false) | ||
}) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @johannes-lindgren 👋
Here, I think it should test the enablePortalModal
right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I don't know what happened here, heh..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dawntraoz, should I revert my recent changes? After the initial feedback, I did add it as an option, and set the default to be disabled, so that it wouldn't be a major version. I moved the documentation to storyblok.com, so there's nothing in the readme file |
Update: After a conversation with @johannes-lindgren we thoughts to go for minor version update and first see how users react to it and just provide docs. In case we get complaints and support tickets we can always upgrade to major. |
If you disabled it and it is just the templates, then indeed, I agree, no need for a major version. I mentioned the README because I saw @BibiSebi mentioned that it would be nice to include it in case of a breaking change, so it is quite clear for anyone looking for answers. But since it will be optional, and then released as a minor version, can you create a ticket to the docs team already to add the option in the main docs: https://www.storyblok.com/docs/plugins/field-plugins/introduction? 🙏 Thanks in advance! |
Thanks for the clarification. I agree the docs are essential. I will personally update the docs 🙂 (I wrote them: https://www.storyblok.com/docs/plugins/field-plugins/storyblok-field-plugin) |
What?
There is an issue that makes various elements on the screen overlap the field plugin modal:
This happens because the field plugin is not using Teleport, but instead uses dynamic styling on its wrapping element to go from
position: relative
toposition: absolute
. But the iframe (and its wrapping div element) might very well not have the highest priority in its stacking context. The way this is normally solved in dialogs is to use<Teleport>
to mount the element outside the stacking context, (somewhere next to the application root element).However, this is not possible to implement without some kind of a breaking change: without the
Teleport
, the iframe element never remounts, which means that the plugin's application state is preserved between. transitions between modal and non-modal modes. But if we conditionally render it inside a<Teleport>
, the iframe element is going to remount, which reset the plugin's application state. Some plugins persist their entire app state in the content—but not all, which is why this would be a breaking change.Rather than making the breaking change in Storyfront, we are introducing an option
enablePortalModal
in@storyblok/field-plugin
which is sent to Storyfront on initialization. This means that the clients will have to manually enable the flag to access this bug ifx. This means that the bug with the overlapping element will persist for all existing field plugins until the authors upgrade and enable the new option.Changes
The solution is to include a new option
enablePortalModal
in the field-plugin SDK: when enabled, and when the field plugin loads, it will include a propertyenablePortalModal: true
in the message to initialize. When set totrue
, the modal will be done with a<Teleport>
, otherwise in the old way.This value is then combined with the
isModal
state (which can be changed by the field plugin or the editor) into a derived valuemodalState
that is in either of the following states:'non-modal' | 'modal-with-portal' | 'modal-without-portal'
.The option
enablePortalModal
is set totrue
in all templates.How to test?
#420 makes it more difficult to test. The sandbox preview won't work because it's not a whitelisted host. So you need to serve the sandbox and demo apps in local development, and update
packages/demo/src/components/FieldPluginDemo.tsx
:Sandbox
In local development mode, you need change the demo application's
targetOrigib
:packages/demo/src/components/FieldPluginDemo.tsx
Then either test with a plugin on the previous versions, or just comment out this line:
packages/field-plugin/src/messaging/pluginMessage/pluginToContainerMessage/PluginLoadedMessage.ts
:The line
enablePortalModal: true,
in