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

feat: Export public interfaces of Node, File and Folder #976

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

susnux
Copy link
Contributor

@susnux susnux commented Jun 5, 2024

I would like to discuss this issue:

If you using those classes in Vue (e.g. in data) they will cause errors, as Vue unrefs data deeply and this causes all private fields to be stripped off from the interface. Passing one of those classes from data to a function that expects e.g. Node will then cause a Typescript error because the passed value is lacking the private fields.

So instead this provides interfaces that can be used whenever a parameter should be of one of those types.

Example of one of those errors:
Screenshot_20240605_131335


Alternative: Cast them every time you use them, like

data() {
  return { content: [] as Node[] }
},
methods: {
  handleConflicts() {
    getConflicts(nodes, this.content as Node[])
  },
},

@susnux susnux requested review from skjnldsv and ShGKme June 5, 2024 11:17
Copy link

codecov bot commented Jun 5, 2024

Bundle Report

Bundle size has no change ✅

@ShGKme
Copy link

ShGKme commented Jun 5, 2024

If you using those classes in Vue (e.g. in data) they will cause errors

Do we need to store them as deep reactive objects?

@ShGKme
Copy link

ShGKme commented Jun 5, 2024

In Vue classes instances (except data classes) aren't usually used in reactive data.

  • Technically - incompatibility with reactivity mechanisms
  • By Vue concept - data storing and data management should be separated

IMO, if we don't consider these object Vue-related entities, we should only work with them as non-reactive, marking raw if needed.

Then, if they are mutable and we need to react on the mutation (e.g. attributes or _data change), we need to either make them reactive initially (by making them Vue-related) or provide a way to handle changes with a wrapper/subscribers.

That's why I asked if we need them to be reactive if we are using them as mutable objects in server/apps.

@susnux
Copy link
Contributor Author

susnux commented Jun 6, 2024

Well mostly I would say no we do not need the node to be reactive but only the wrapping array.
So a shallowRef or shallowReactive would be good enough, though I do not know if you can use them in Options API without setup?

@ShGKme
Copy link

ShGKme commented Jun 6, 2024

toRaw must work in data in Vue 3, and we can emulate it by adding something like __v_RAW to these classes initially, but I never tested it in Vue 2.

@ShGKme
Copy link

ShGKme commented Jun 6, 2024

Adding __v_skip: true for both Vue 2 and Vue 3 to these classes will remove them from being observed/mutated/reactive anywhere in Vue

@susnux
Copy link
Contributor Author

susnux commented Jun 8, 2024

I adjusted the dialogs file picker as a first step by using shallowRef and shallowReactive which should be good enough.

Copy link

@ShGKme ShGKme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, this PR may still make sense to use, where we don't need an actual Node/File instance

@susnux susnux added the enhancement New feature or request label Jun 12, 2024
If you using those classes in Vue (e.g. in data) they will cause errors,
as Vue unrefs data deeply and this causes all private fields to be stripped off from the interface.
Passing one of those classes from data to a function that expects e.g. `Node` will then
cause a Typescript error because the passed value is lacking the private fields.

So instead this provives interfaces that can be used whenever a parameter should
be of one of those types.

Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
@susnux susnux force-pushed the feat/export-public-interface-nodes branch from 83266c5 to 3e50052 Compare June 14, 2024 11:27
@susnux susnux merged commit 2a13c48 into main Jun 14, 2024
17 checks passed
@susnux susnux deleted the feat/export-public-interface-nodes branch June 14, 2024 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants