-
Notifications
You must be signed in to change notification settings - Fork 745
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
Separate frontend core API into 'public' and 'internally shared' #5488
Labels
Milestone
Comments
9 tasks
3 tasks
2 tasks
9 tasks
2 tasks
This was referenced Oct 3, 2024
🎉 congratulations! |
5 years in the making! |
Step by step :) Good work. Hi @indirectlylit! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, all core shared components are loaded onto the core API object, which leads to a large, bloated object that we load on every single page of Kolibri.
In conversation with @indirectlylit, we posited that the purposes of the core API would be better served by a two tier structure:
The public, core API. This would be available to external plugins, and accessable on the
kolibriGlobal
object on thewindow
object. (this would be a subset of what is currently exposed in this way). These would be available in thekolibri
core package, under the same file paths as used for import, but for plugin builds, they would map to the kolibriGlobal object at runtime.A shared, internal, library. This would be available at build time for use in Kolibri. The intention of this is to allow us to more easily share components across different internal plugins, without having to overload the core API. These would be put into the
kolibri-common
package, which will not be published, nor supported for external usage.Lastly - we will continue to use KDS as a place for public, shared components and functionality.
Current single purpose modules that need to be imported independently of the core API (
kolibri_module
,kolibri_app
,content_renderer_module
, andplugin_data
) will be migrated to separate packages that are published to NPM.The proposed mapping of the current API to this new format would be as follows (null indicates it would be removed):
This spec would also be used to create a new migration script to do the updating of import paths automatically, which could then be used by plugins for an easy migration path (but would throw a warning of anything not exposed by
kolibri
is used).Prerequisites
Tasks
The text was updated successfully, but these errors were encountered: