Skip to content
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

Merged
merged 13 commits into from
Oct 16, 2024

Conversation

johannes-lindgren
Copy link
Collaborator

@johannes-lindgren johannes-lindgren commented Oct 3, 2024

What?

There is an issue that makes various elements on the screen overlap the field plugin modal:

image

This happens because the field plugin is not using Teleport, but instead uses dynamic styling on its wrapping element to go from position: relative to position: 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 property enablePortalModal: true in the message to initialize. When set to true, 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 value modalState that is in either of the following states: 'non-modal' | 'modal-with-portal' | 'modal-without-portal'.

The option enablePortalModal is set to true 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:

  const { type, data, actions } = useFieldPlugin({
    validateContent,
    // Storyfront in local development mode
    // targetOrigin: 'http://localhost:3300',
    // Sandbox in local development mode:
    targetOrigin: 'http://localhost:7070',
  })

Sandbox

In local development mode, you need change the demo application's targetOrigib:

packages/demo/src/components/FieldPluginDemo.tsx

export const FieldPluginDemo: FunctionComponent = () => {
  const { type, data, actions } = useFieldPlugin({
    validateContent,
    targetOrigin: 'http://localhost:7070',
  })

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

export const pluginLoadedMessage = (
  options: Pick<PluginLoadedMessage, 'uid' | 'callbackId'>,
): PluginLoadedMessage => ({
  action: 'plugin-changed',
  event: 'loaded',
  fullHeight: true,
  subscribeState: true,
  enablePortalModal: true,
  ...options,
})

Copy link

vercel bot commented Oct 3, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
plugin-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 16, 2024 0:49am

@johannes-lindgren johannes-lindgren changed the title fix(sandbox,lib,demo): modal in portal fix(sandbox,lib,demo)!: modal in portal Oct 3, 2024
@eunjae-lee
Copy link
Contributor

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.

@johannes-lindgren
Copy link
Collaborator Author

johannes-lindgren commented Oct 4, 2024

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 enablePortalModal as an argument to createFieldPlugin. That would benefit all plugins that gets created from this point onward because we could set it as default in the starters. But the drawback with that approach is that we don't force older plugins to deal with the issue. It also required more code, as we'll need to pass the parameters around, even when that parameter should be the default.

@johannes-lindgren
Copy link
Collaborator Author

johannes-lindgren commented Oct 8, 2024

What do you think, @demetriusfeijoo, @Dawntraoz, @BibiSebi, @eunjae-lee? Major or minor version?

@demetriusfeijoo
Copy link
Contributor

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 enablePortalModal: true by default, so most of the new plugins created based on them are already covered.

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. 🤔

@johannes-lindgren
Copy link
Collaborator Author

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.

@BibiSebi
Copy link
Contributor

BibiSebi commented Oct 9, 2024

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).

@johannes-lindgren
Copy link
Collaborator Author

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.

@johannes-lindgren johannes-lindgren changed the title fix(sandbox,lib,demo)!: modal in portal fix(sandbox,lib,demo): modal in portal Oct 9, 2024
@johannes-lindgren johannes-lindgren marked this pull request as ready for review October 9, 2024 14:20
@johannes-lindgren johannes-lindgren changed the title fix(sandbox,lib,demo): modal in portal feat(sandbox,lib,demo): modal in portal Oct 9, 2024
@johannes-lindgren
Copy link
Collaborator Author

johannes-lindgren commented Oct 9, 2024

@demetriusfeijoo, @BibiSebi, @Dawntraoz, I added an option to createFieldPlugin.

@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:

  • Ecommerce
  • Bynder
  • Table (used by customers)
  • Annotated image (not sure how important)

Did I miss some?

@demetriusfeijoo
Copy link
Contributor

Hey @johannes-lindgren 🙌

I started reviewing it but didn't manage to finish it yet.
I'll focus on this and the one on the Storyfront side tomorrow.

These are the ones I can think of:
Ecommerce
Bynder
Table (used by customers)
Annotated image (not sure how important)
Did I miss some?

Oh, I didn't know about Table and Annotated image.
From the top of my mind, I'd just include the Picker Starter on that list.

@BibiSebi
Copy link
Contributor

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.

CC: @johannes-lindgren @demetriusfeijoo @Dawntraoz

@johannes-lindgren
Copy link
Collaborator Author

@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?

@johannes-lindgren
Copy link
Collaborator Author

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?

@Dawntraoz
Copy link
Contributor

Dawntraoz commented Oct 11, 2024

@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 field-plugin, and then the same for field-plugin-cli afterwards, as per the release guidelines: https://github.com/storyblok/field-plugin/blob/main/CONTRIBUTING.md#release.

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 🤔

Copy link
Contributor

@demetriusfeijoo demetriusfeijoo left a 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:

image

I have left a comment about the tests which I think may be wrong but overall, the change looks good to me. 👏 👏

Comment on lines 124 to 168
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)
})
})
Copy link
Contributor

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?

Copy link
Collaborator Author

@johannes-lindgren johannes-lindgren Oct 16, 2024

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..

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johannes-lindgren
Copy link
Collaborator Author

johannes-lindgren commented Oct 15, 2024

@johannes-lindgren @BibiSebi @demetriusfeijoo After reading the discussions, these are my 2 cents:

Johannes, can you include the option in the README.md so it is already documented? In that case, I would then merge as-is, release a major version for field-plugin, and then the same for field-plugin-cli afterwards, as per the release guidelines: https://github.com/storyblok/field-plugin/blob/main/CONTRIBUTING.md#release.

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 🤔

@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

@BibiSebi
Copy link
Contributor

BibiSebi commented Oct 16, 2024

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.

CC: @Dawntraoz @demetriusfeijoo

@Dawntraoz
Copy link
Contributor

@johannes-lindgren @BibiSebi @demetriusfeijoo After reading the discussions, these are my 2 cents:
Johannes, can you include the option in the README.md so it is already documented? In that case, I would then merge as-is, release a major version for field-plugin, and then the same for field-plugin-cli afterwards, as per the release guidelines: https://github.com/storyblok/field-plugin/blob/main/CONTRIBUTING.md#release.
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 🤔

@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

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!

@gustavomelki gustavomelki merged commit 1ceeda4 into main Oct 16, 2024
4 checks passed
@gustavomelki gustavomelki deleted the SHAPE-7187-modal-with-portal-in-field-plugin branch October 16, 2024 12:50
@johannes-lindgren
Copy link
Collaborator Author

@johannes-lindgren @BibiSebi @demetriusfeijoo After reading the discussions, these are my 2 cents:
Johannes, can you include the option in the README.md so it is already documented? In that case, I would then merge as-is, release a major version for field-plugin, and then the same for field-plugin-cli afterwards, as per the release guidelines: https://github.com/storyblok/field-plugin/blob/main/CONTRIBUTING.md#release.
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 🤔

@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

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants