# WIP: Remove V parameter on elements \(\#3366\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/361801e527d508e0af9979d823f05a3a228290f5)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 361801e527d508e0af9979d823f05a3a228290f5

Requested commit: 361801e527d508e0af9979d823f05a3a228290f5

Commit: 361801e527d508e0af9979d823f05a3a228290f5

Tree: ff8363f0f25769f14b4be60ed2f6f9140b5b5e11

Author: Mikayla Maki

Committer: GitHub

## Message

```
WIP: Remove V parameter on elements (#3366)

This is an exploration of what it would take to remove the `V` generic
from the element type. Answer: less than I expected.

I added a new struct to GPUI2: `CallbackHandle<Event>`, and reworked the
interactivity related APIs to take this type. I also added a
`.callback()` function to `ViewContext` that can construct a
`CallbackHandle` to wrap our current `|&mut View, &Evt, &mut
ViewContext| {...}` based APIs. With these two changes, we can now
capture the context of the callsite of a click handler, allowing us to
capture all relevant types and data _before_ sending them into GPUI.
This lets us achieve a similar programing style to the existing system,
while also letting us remove all of the generics from the entire element
system. For an example of what this looks like in practice, here's a
side by side diff of the test in `interactive.rs` (which compiles and
passes):

<img width="1310" alt="Screenshot 2023-11-19 at 7 32 08 PM"
src="https://github.com/zed-industries/zed/assets/2280405/596f2a9a-9c8e-4158-bf6d-0003cf973015">

Note how the new arrangement of types is more amenable to rust's type
inference, allowing the code to be just as terse as before despite the
extra function call in the middle.

This approach also allows components to provide well typed APIs to
views, without ever knowing that view's type. This PR includes an
example rewrite of the button component in `ui2`, here's what it's
struct could look like now:

<img width="1105" alt="Screenshot 2023-11-19 at 7 24 28 PM"
src="https://github.com/zed-industries/zed/assets/2280405/fc98d3c2-6831-4c0f-a324-ab0fae33b0bc">

However, I have not yet ported the derive macro for Component to this
new structure, as I know @nathansobo is currently reworking that code.

Once that macro has been rewritten, it should be relatively easy to
rewrite the rest of Zed2 with this approach, the only major difference
that I can foresee is that the editor element would need to wrap it's
operations in an update callback. Though I can think of a few ways to
fix this with a new `ViewElement` trait, that does the wrapping for you.
```

## Parents

- [30962226722bf534daa8c6aa00fc51de4cbd83c0](https://git.cafe/gitcafe/zed/commit/30962226722bf534daa8c6aa00fc51de4cbd83c0?format=markdown)

- [a844bf7d41f5215cdae29e3385c99d4f3bc68753](https://git.cafe/gitcafe/zed/commit/a844bf7d41f5215cdae29e3385c99d4f3bc68753?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/361801e527d508e0af9979d823f05a3a228290f5?format=markdown)