Updating 19.1 beta to support modular platform overrides #741
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Create mixed platform and browser windows * Update readme with old method for all platform windows
Initial example of putting a pattern around how a platform can use notifications across multiple teams within a platform. The idea is to introduce a level of isolation between modules and allowing modules to be grouped and have settings to specify whether they should be a part of a platform or just show up in the all tab. Plus the options around whether the icon from a module should be enforced when it comes to notifications. This pattern also means that modules do not need to bundle notification code from the workspace module as it is injected. It also ensures all modules use the same version. - Notification Client created and Notification Provider supports a getNotificationClient function that can be passed options. - Docs updated - Changelog updated - Example lifecycle module added demonstrating notification client use. - Main manifest updated with example lifecycle module reference but disabled.
* Added initial support to fdc3.open and passed fdc3 2.0 open tests * Added logic for awaiting instanceId on broker connection When opening an app via fdc3 we should await the connection to the broker to get the endpointId which acts as a unique instance id that cannot be specified by an app. * Updated findInstances so that it can find all app instances but, if you are looking for instances to show in an intent picker then narrow it down to only include the app if it has registered an intent handler. * Updates for fdc3 2.0 conformance * Support context listeners that act as a context type catch all and update docs. * Ability to turn off window positioning strategy and extra defensive coding for window positioning strategy * Added additional error handling around trying to determine if a window is visible and what it's bounds are because during an automation related test where many windows are being launched and closed there is a chance that a reference to a window no longer exists when you try to get whether it is showing or it's position. As window layout strategy is really for an end user it serves little benefit during testing where the goal is to run automation tests as quickly as possible. Therefore the option to disable the window positioning strategy has been added. * Added a try catch around logging the created window options In some automation scenarios this window may be closed shortly after creation so we want to ensure there are no errors bubbling for what is a developer support information and not core functionality. * Update doc based on feedback
* Add favorites support to pages and workspaces * Updated based on feedback * Update based on feedback * Added deprecated theme methods * Correct menu location depending on menu type * Add icon support to native menu * Custom menu disabled option
* Added support for new mixed platform window support Added support for launchPreference where you can specify some settings for views or windows with an extra option for views where you can specify a platform window instead of a browser window. Added a platform window example with theme support. Added support for apps-*.json for schema support for intellisense. * Updated app related docs to include launchPreference setting.
* Add full custom popup menu support for platform overrides
* Updated launchPreferences Added a number of additional options and moved them to a host object within view. Updated platform window to use title if provided
The page composite module now supports launching/showing a page by specifying init params (similar to querystring params). This will either launch the page or bring it to front if it was already loaded.
It is launched using the following structure:
fins://domain/yourmanifest.fin.json?$$action=show-page&$$payload=eyAicGFnZUlkIjogImIwY2UxNTg3LTM2ZDAtNGRlZC05ZGU3LTlmNmQyYjc1OGYyNyIgfQ==
A localhost example:
fin://localhost:8080/manifest.fin.json?$$action=show-page&$$payload=eyAicGFnZUlkIjogImIwY2UxNTg3LTM2ZDAtNGRlZC05ZGU3LTlmNmQyYjc1OGYyNyIgfQ==
The payload is a base64 encoded string of a json object containing a pageId e.g.
{ "pageId": "b0ce1587-36d0-4ded-9de7-9f6d2b758f27" }
This pageId is unlikely to exist on your setup but it is just an example.
The module is enabled via the initProvider configuration in manifest.fin.json but the configuration can be disabled or removed if you don't want this support.
"initOptionsProvider": {
"modules": [
{
"enabled": true,
"id": "show-page",
"title": "Init Options Show Page",
"url": "http://localhost:8080/js/modules/composite/pages.bundle.js",
"data": {
"supportedActions": ["show-page"]
}
}
]
},
The launchPage helper method passed to modules has been updated so that it now accepts a pageId instead of requiring modules to look up the page object and pass it.
the condition function (used to check to see if a certain condition is true) has also been moved from integration helpers to the base module helpers object to allow more modules to check for conditions.
Changelog has been updated to include the changes.
* Add global settings for menu styles * Remove fav warning if disabled * Update changelog
* Updated module helpers to allow platforms to expose endpoints to module developers. * Updated docs * Applying feedback
… make the picker monitor aware
- Breaking Change - We have updated the way an interop broker communicates with an intent picker window. We were using a reference to the WebWindow to add a function from the broker to the intent picker window. This works but would not work cross domain. OpenFin also introduced the showPopupWindow API since this approach was used so we have now switched to using the showPopupWindow which works cross domain. This means that you can not build you own intent window that receives the list of applications and intent/context via customData passed to the window and it can return the selection using await fin.me.dispatchPopupResult({ appId, instanceId, intent }); if a selection is made or await fin.me.dispatchPopupResult(); if the user cancelled the intent selection. Our example intent pickers have been updated: [instance-picker.html](./public/common/windows/intents/instance-picker.html) and [picker.html](./public/common/windows/intents/picker.html)
- New Feature - The intent picker now tries to appear in the center of the monitor from where the intent was raised (rather than always showing up on the main monitor).
- Fix - Fixed the basic intent picker that wasn't working correctly.
* Popup menu improvements * Update changelog
* Fix image conversion for menus * Fix linting
* InteropBroker refactor Broken out some of the helper functions from the interopbroker and also removed the intent related functions from the app provider.
…elpers (#588) Removed the theme related functions that were at the root of module helpers as they are now available through getThemeClient. The TS Types are there to indicate they no longer exist and the changelog has been updated to reflect the change. This now follows our getXClient pattern. New support for specifying endpoints for fetching the manifest json url specified in an app definition. A platform can specify an endpoint called manifest-get if it wants to override the default fetch. If a platform wants a specific behavior for a specific app then they can set an endpoint called manifest-get-app-id. The default fetch implementation for endpoints has been enhanced. Now you can have an endpoint defined with different options for fetch but no url and have the request contain the url when calling request/response etc. This is used to allow platform devs to provide additional fetch options specific to their platform but have the manifest url passed without the need to have a custom endpoint module created. e.g. { "id": "manifest-get", "type": "fetch", "options": { "method": "GET" } }
…and added notification examples (#725) Updated existing modules and template * Introducing stream support to endpoints an example of being able to request notifications We include examples of notifications being triggered via the platform using the channel api or intents. * Additional scenarios covered. - Updated WPS Interop Broker implementation so that it includes fdc3 app instances if they exist in the array of apps returned when findIntent is called as recommended by the FDC3 documentation. - Extended endpoint so that we now have a requestStream option for those implementing endpoints that want to return a stream of data instead of a simply requestResponse. - Included an example of the the requestStream endpoint by implementing an example source of notification data in the modules/endpoint/example-notification-source - Added an example of a lifecycle module that handles notifications coming from the notification source as well as notifications that have been sent to it. This shows how you can standardize some types of notification actions: raise-intent, launch-app, broadcast (option to broadcast on an app channel or user channel). This is just an example showing how you could expose an API to your content using an SDK approach using the Channel API or intents. This is a basic example and there are many more things to consider but it is intended as an example for a discussion around options.
…d a preload that shows the snap debug window. (#726)
Update versions, version urls and salesforce starter based on feedback
…/workspace-starter into workspace/vnext
johnman
requested review from
ameetj85,
adam-saland,
joeransegnola and
raycashmore
joeransegnola
approved these changes
Aug 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.