From 905fe766aff228bb343e1faa52d451d910d65594 Mon Sep 17 00:00:00 2001 From: Jason Wesson Date: Fri, 18 Aug 2023 19:33:01 +0000 Subject: [PATCH 1/2] docs: Add ADR for handling frontend plugin fallback --- .../0008-frontend-plugin-fallback.rst | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 docs/decisions/0008-frontend-plugin-fallback.rst diff --git a/docs/decisions/0008-frontend-plugin-fallback.rst b/docs/decisions/0008-frontend-plugin-fallback.rst new file mode 100644 index 000000000..03294fca1 --- /dev/null +++ b/docs/decisions/0008-frontend-plugin-fallback.rst @@ -0,0 +1,38 @@ +How to Handle Frontend iFrame Plugin Fallback +====================================================================================== + +Status +------ + +Draft + +Context +------- +The Frontend Plugin Framework's iFrame class implementation will live in Frontend Platform, +but the question of how we want to handle the case where the iFrame fails to render needs to +handled. + +Given that this is a new feature that is being made available to the frontend, we +can't anticipate all of the ways that the plugin will be used for a given repo, nor do we +have any intention to limit the scope of how it can be used. Because we don't all of the use +cases for the plugin, we also don't know the desired fallback method that is desired for any +given plugin. + +Decision +-------- +For the above reasons, we will have failing iFrame plugins return an H1 tag that +says "There was an error.". By doing so, it is up to the engineer/team that implements the plugin +to handle the desired fallback however they would like. + +Rejected Alternatives +--------------------- + +The initial assumption was that we should determine what the fallback would be +if the iFrame plugin render failed. The extent of what this handling could look like +ranges from taking in a fallback argument to providing the same fallback image no matter +how the plugin was being used. These options limit the possibilities for how the fallback +-- and the plugin itself -- would present itself by assuming each plugin implementation +or desired fallback method will be the same for all plugins. + +.. _oepXXXX: https://github.com/openedx/open-edx-proposals/pull/287 +.. _frontend_plugin_roadmap: https://github.com/openedx/platform-roadmap/issues/27 \ No newline at end of file From 4c78b7f81235f034f061f553335f8c0eee791f47 Mon Sep 17 00:00:00 2001 From: Jason Wesson Date: Wed, 27 Sep 2023 10:59:57 -0700 Subject: [PATCH 2/2] Update docs/decisions/0008-frontend-plugin-fallback.rst Co-authored-by: Zainab Amir --- docs/decisions/0008-frontend-plugin-fallback.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0008-frontend-plugin-fallback.rst b/docs/decisions/0008-frontend-plugin-fallback.rst index 03294fca1..e0987a0e5 100644 --- a/docs/decisions/0008-frontend-plugin-fallback.rst +++ b/docs/decisions/0008-frontend-plugin-fallback.rst @@ -14,7 +14,7 @@ handled. Given that this is a new feature that is being made available to the frontend, we can't anticipate all of the ways that the plugin will be used for a given repo, nor do we -have any intention to limit the scope of how it can be used. Because we don't all of the use +have any intention to limit the scope of how it can be used. Because we don't know all of the use cases for the plugin, we also don't know the desired fallback method that is desired for any given plugin.