Ref, ConstRef, StringRef and other adapters

[mark2185]

Why are these necessary? I couldn't figure it out from the code.

I tried removing the Ref adapter and using C++'s references instead and it compiles okay. At first it seems like boilerplate code.

[ArthurSonzogni]

Yes, you can pass either a reference to something you own: T* or pass ownership of the object directly: T
You are not meant to use Ref directly, this is an adapter.

---

One thing I observed:

1. It is much easier to write a functional UI, when the "data" is not stored by UI components, but provided and owned externally by the user instead. This way, any change on the data is always reflected into the component, without need for synchronization. One source of trust == easy to use.
2. This force users to pass a reference to their data. However, sometimes this is a lot of boilerplate:

• The "optional" values. Most of the time folks are fine with the default value. They don't want to store default option somewhere.
• The values meant to be constant. Folks would like to pass directly constant data without storing it somewhere and referencing it.

Ref is an adapter. It represents either a reference to an external object, or an object it owns. This way, developers can pass either T or T*.

StringRef are like Ref, but with the added capability to convert std::wstring <=> std::string automatically. This helped me switching from an API using UTF-16 std::wstring toward an API using UTF-8 std::string, without breaking legacy users.

Does this help?

[mark2185]

I get that it can take either a reference to something "borrowed" or take ownership directly, it's just that I'm confused why is this necessary as an adapter when the language supports both use cases through lvalue and rvalue references.

Sending T* (or from the user's perspective &t) seems unnecessary when the component can just expect T & in its constructor. It still has one source of trust.
If a user wants to pass the ownership, it should be passed as a temporary object or moved when creating the object.

It is much easier to write a functional UI, when the "data" is not stored by UI components, but provided and owned externally by the user instead. This way, any change on the data is always reflected into the component, without need for synchronization. One source of trust == easy to use.

Couldn't you pass by value and have a getter that returns a reference? Godbolt example.
It bypasses the need for adapters, and it is on the user to user to request for a "automatically synced flag" if they want to.

The values meant to be constant. Folks would like to pass directly constant data without storing it somewhere and referencing it.

That's handled with Data if it can be copied or Data && if it needs to be moved.

As for ConstRef, judging by the name it should be read-only, so I see no reason not to use const &.

The std::wstring <=> std::string automatic conversion makes sense.

[ArthurSonzogni]

Couldn't you pass by value and have a getter that returns a reference? Godbolt example.

It is essential for the component to be able not to "own" the data.

For instance, let say you to implement a tab bar, displaying multiple subcomponent, depending on the value selected.

  std::vector<std::string> tab_values{"tab_1", "tab_2", "tab_3"};
  int tab_selected = 0;
  auto tab_toggle = Toggle(&tab_values, &tab_selected);

  auto tab_container = Container::Tab({
          [...] // Component for tab 1.
          [...] // Component for tab 2.
          [...] // Component for tab 3.
      },
      &tab_selected);

  auto final_component = Container::Vertical({
      tab_toggle,
      tab_container,
  });

You see "tab_selected" is both referenced from the Toggle (to select the right tab) and from Container::Tab (to display the right tab)

If Toggle or Container::Tab was owning their own version of "tab_selected", we would have to implement some synchronization in between them.

[mark2185]

If Toggle or Container::Tab was owning their own version of "tab_selected", we would have to implement some synchronization in between them.

Would we? Multiple references pointing to the same value, no synchronization needed.

  std::vector<std::string> tab_values{"tab_1", "tab_2", "tab_3"};
  auto tab_toggle = Toggle(&tab_values, 0);
  auto & tab_selected = tab_toggle.selectedTab();

  auto tab_container = Container::Tab({
          [...] // Component for tab 1.
          [...] // Component for tab 2.
          [...] // Component for tab 3.
      },
      tab_selected);

  auto final_component = Container::Vertical({
      tab_toggle,
      tab_container,
  });

EDIT: I see, the Container::Tab constructor would have to pass-by-reference, which defeats my idea of not having references passed in constructors.

I admit, when they have such dependency on an external/global value, it does complicate things.

I'm convinced!