A proposal for a new type to describe component and agent references

[huntc]

I'd like to propose that we (re-)introduce a new type to describe references to components and agents. Presently, these are named "links". Links are references to scopes in the case of components. My position is that reference should be an opaque type entirely for the purposes of addressing a component or agent. As it stands, we are leaking the notion of "scope" to the caller when we are strictly conveying an address of a component.

I see that Components V2 removed ComponentLink but I cannot find any rationale as to why. There was some questioning on the context's link method returning a Scope, but that is the only commentary I have found to-date. In addition, the AgentLink has been retained, which now feels inconsistent in that there is no longer an equivalent for components.

In actor libraries such as Akka, these references are known as ActorRefs.

The suggestion I have is to provide a type named, ComponentRef for components and AgentRef for agents. As these types reference different types of things, I would think it is reasonable to have two types of addressing mechanisms (as we do/did). Over time, these types might also contain different internal representations to be able to address components and agents.

EDIT: I removed a proposed solution of “self” and “ref” naming as its more important to focus in on the goal, which is to have a separate type to address components, and make that consistent with addressing agents.

[ranile]

self seems like a horrible name for a function.

Also, as I mentioned for discord, ComponentLink was just a type alias which served no purpose. It has been removed in favor of just using the type directly. If you have a better name for the scope type, I would like to hear it. I'm against introducing a new alias like ComponentLink though.
Also see #2011

[siku2]

self is a keyword and so is ref. Technically ref can be used as a raw identifier (r#ref), but r#self doesn't compile at all.

[huntc]

ComponentLink was just a type alias which served no purpose. It has been removed in favor of just using the type …

A scope isn’t a link.

[huntc]

If you have a better name for the scope type, I would like to hear it

My suggestion is to retain Scope and introduce ComponentRef

[siku2]

I think it makes sense, conceptually, to separate these types, but so far I'm not convinced it's worth the breaking change.
From the user's point of view nothing really changes except the name.

[huntc]

The naming of a type is important to the user.

[huntc]

self is a keyword and so is ref.

I realise this but didn’t realise that self() wouldn’t be permitted. Perhaps own() then or something else. I was also trying to point out what other libraries call it.

[huntc]

I removed a proposed solution of “self” and “ref” naming as its more important to focus in on the goal, which is to have a separate type to address components, and make that consistent with addressing agents.

[mc1098]

Thank you for the discussion and the outside perspective using Akka 🎉 Always awesome to see different sides to things IMO ❤️

I do agree here that with ComponentLink gone AgentLink feels odd, but I think we can split this apart in some ways because yew_agent the module within Yew will be yew-agent the external public crate. I don't think many people would argue that agents needs some TLC. It also has an issue for a V2 in it's own right #1708, and I've added a quick comment there about AgentLink being out of sync.

I'm not in love with the names of either link or Scope, and I hesitated with the removal of ComponentLink because it was the status quo and I'm of the mind that unless something is an improvement the status quo should remain. I do, however, feel that generally an alias should be objectively more clear about the behaviour or purpose of a type. For example the ShouldRender alias is objectively clear what that type is for and if it was an alias for anything more complicated than a bool I would have wanted to keep it! I don't get that same feeling with ComponentLink, it's still feels just as vague as Scope imo.

I have no issue with bringing back a type alias for Scope if it adds some clarity -- it doesn't have the same issues as ShouldRender did in terms of importing because you will only ever use the actual type Scope now if you are trying to pass a component scope somewhere else, actually it's more about the code that will receive the Scope. This is because the Scope lives in Context<Self> and isn't required to be held by the component.

My suggestion is to retain Scope and introduce ComponentRef

Maybe this is just me:

let x: &Component = //..

When considering x I think of it as "x is a Component ref" , I know really it should be "x is a reference to a Component" but I can't help it 🙃 so for me this conflicts in my mind, but I will admit this is probably because I have a weird way of thinking about the above code 😅

As a short aside..

but r#self doesn't compile at all.

I didn't know that 😅