Investigation, delete value.value to access some components

[JaimeTorrealba]

Description

Currently some abstraction in cientos, need to be access by value.value at the moment of reference them

As a good DX we need to find a solution to this detail.

The problem is located in the EJ:

defineExpose({
value: starsRef,
})

Suggested solution

If you have a good solution, please explain it here

Alternative

No response

Additional context

No response

Validations

• I agree to follow this project's Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[JaimeTorrealba]

@andretchen0 bro I trust a lot in you, so sorry if you feel I'm given you work (please don't think so, I would like your comments in this subject)

As you know soon will be release the v4 and is our opportunity to introduce some breaking change to improve the pkg.

How do you feel about this? Are you comfortable with the value.value pattern? Do you have any problems with it?
I personally don't like it, but my solutions also don't convince me 😮‍💨

I don't feel good that if you want to access to (for example a box/shape) you have to do it with

const boxRef = shallowRef()

watch(boxRef , value =>{
value.value = .....
})

// or worse

onLoop(() => {
 if (boxRef.value){
 boxRef.value.value.position.x = ...
 }
})

[JaimeTorrealba]

@alvarosabu Your appreciation here will be highly valuable too.

As far I can see, we could standardize this one with other word, like "current" or "instance". Having another point of view will be fantastic.

Or we could just leave as it is.

Of course no rush

[alvarosabu]

I completely agree @JaimeTorrealba , what about ref since is a reference of the instance, or well instance is ok to, whatever is shorter for the chaining boxRef.ref.value

We would need to replace:

defineExpose({
  value: controlsRef,
})

With

defineExpose({
  ref: controlsRef,
})

[JaimeTorrealba]

In that case will be boxRef.value.ref, but yeah I like it

[andretchen0]

Hey @JaimeTorrealba @alvarosabu ,

How do you feel about this? Are you comfortable with the value.value pattern? Do you have any problems with it? I personally don't like it, but my solutions also don't convince me 😮‍💨

I agree. I would like to change value.value.

Idea 1

For Cientos, we're mostly just exposing the root Object3D. What do you guys think of this?

<script setup>
// ...
// NOTE: the Object3D that will serve as the root for this component
const root = new Object3D();
defineExpose(root)
</script>

In the parent, it's used like this:

<script setup>
// ...
const levioso = ref(null)
const box = ref(null)
watch(levioso, () => console.log(levioso.value.isObject3D))
watch(box, () => console.log(box.value.isObject3D))
</script>

<template>
<Levioso ref="levioso">
    <Box ref="box" />
</Levioso>
</template>

Idea 2

Otherwise, if we want to leave room for exposing other fields, maybe ... :

defineExpose({
    root,
    someUsefulFunction
})

... which gives us ... :

watch(levioso, () => console.log(levioso.value.root.isObject3D))

I think many/most Vue/Three users will understand "root" (as in "root node of the child") without need for further explanation. And "root" couples nicely with digging down into the subtree:

levioso.value.root.children

We'd need to figure out other names for e.g., what's in defineExpose from useFBO.

[alvarosabu]

Hi, @andretchen0 I remember we added the .value to the expose because you can't pass ref or reactive, only plain objects. dunno if it's still a restriction.

I like the second idea.

[andretchen0]

I remember we added the .value to the expose because you can't pass ref or reactive, only plain objects. dunno if it's still a restriction.

Sure thing. As of today, passing plain values or refs is documented.

[alvarosabu]

Let's do it. @JaimeTorrealba please create a todo list of all the components that need change on the ticket and let's go for it.

Since this will be a breaking change, please open the branch from v4

[JaimeTorrealba]

Perfect. Let's stick with "root" as Andre points, we could expose more than one instance (method, etc).

Wait a PR soon ...