-
Notifications
You must be signed in to change notification settings - Fork 208
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
(fix) Various fixes for compatibility of new versions #707
Conversation
* esm-framework itself should use System-style output * Properly handle multiple routes overriding each other * Properly handle ordering of pages across apps and app indices based on page order
Size Change: -232 kB (-10%) 👏 Total Size: 2.11 MB
ℹ️ View Unchanged
|
@@ -182,22 +182,26 @@ export function registerApp(appName: string, routes: OpenmrsAppRoutes) { | |||
* Each page is rendered into a div with an appropriate name. | |||
*/ | |||
export function finishRegisteringAllApps() { | |||
pages.sort((a, b) => a.order - b.order); |
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.
So, I think we were implicitly relying on sorting pages by app and then by page order. Pages are now sorted purely by order (and then appName according to English rules) so we're not implicitly relying on anything.
This is also why the index-counting behaviour needed to be changed to track an index-per-app.
let index = 0; | ||
let lastAppName: string | undefined = undefined; | ||
|
||
let appIndices = new Map(); |
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.
We probably have a lot of places where we're using Objects and it would make sense to use Maps. That said, the syntax for objects is much more comfortable, i.e., I don't think there's as ergonomic a version of {...base, ...overrides}
for merging maps as for objects, though I suppose:
function mapMerge(base: Map, overrides: Map): Map
wouldn't be hard to write.
*/ | ||
async function setupApps() { | ||
const scriptTags = document.querySelectorAll<HTMLScriptElement>( | ||
"script[type='openmrs-routes']" | ||
); | ||
|
||
const promises: Array<Promise<typeof window.installedModules>> = []; | ||
const promises: Array<Promise<OpenmrsRoutes>> = []; |
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.
We process each script tag asynchronously, but we need to merge them into a single consistent view of routes before we do anything else. We were accidentally double-loading some routes in development, which was not great.
); | ||
|
||
const modules: typeof window.installedModules = []; | ||
Object.entries(routes).forEach(async ([module, routes]) => { |
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.
Technically, this doesn't guarantee that all modules will be in installedModules
, i.e., the array can continue to grow asynchronously. I don't know if it's worth implementing the kind of blocking that would be required to ensure that once it was set it's value was not changed.
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.
LGTM
Requirements
For changes to apps
If applicable
Summary
Screenshots
Related Issue
Other