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

New package structure #99

Open
4 of 7 tasks
ognen opened this issue Feb 12, 2018 · 1 comment
Open
4 of 7 tasks

New package structure #99

ognen opened this issue Feb 12, 2018 · 1 comment

Comments

@ognen
Copy link
Member

ognen commented Feb 12, 2018

As it becomes apparent that parts of the framework, need to be useful in a Node environment, it becomes necessary to restructure the packages a bit better. Additionally, we are gearing up towards a rename, so we could use the occasion to introduce the new package structure.

I think the new package structure should look like:

  • config -- as is now, no change
  • components -- as is now
  • system -- the system/subsystem framework extracted into a separate module:
    • the System no-longer offers a redux store but is a simple micro DI framework (will need some refactoring)
  • core -- the future core package contains the following features (usable from all supported environments):
    • data, registry, zip
    • logging internals
  • transforms -- the transform, enrich, enhance subsystems, allowing registration and access to transforms. Can be used in React, RN, Node
  • app -- this package contains
    • store (a new subsystem that provides the redux-store, dispatch and middleware handling)
    • ui, read, effect, update subsystems
  • classic a backwards compatibility package that users of girders-elements initially switch to.

Furthermore, the core package's kernel should be re-considered within a koa-drven multi-phase scenario. What primitives do we add there?

@bevkoski, @andon thoughts?

@bevkoski
Copy link
Collaborator

I would put transform, enhance and enrich in a single package named transformation or transforms.

Regarding the last package, I would definitely go with the name app rather than react.

andon added a commit that referenced this issue Aug 30, 2018
The @skele/core package contains the following features (usable from all supported environments):
* data, registry, zip
* logging internals

It's mostly extracting it from @skele/classic with using it as a dependency in there, while preserving the same API.

More details about the new package restructuring: #99
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

No branches or pull requests

2 participants