Signal Trait proposal, make it more powerfull!

[anuoua]

Signal Trait Proposal

Hey, I believe signals are missing a crucial feature, and that is the concept of "traits."

Problem Scenario

When dealing with a complex and massive object, it becomes impractical or costly to regenerate it every time there is a change. Signals seem to face difficulties in updating in such scenarios. As an example, consider the use of OpenLayers in the following scenario. The map object is highly complex, making it challenging to regenerate the entire map reference when internal properties are updated, thus preventing the signal from updating.

const map = signal(new OpenlayersMap({
  layers: [
    new TileLayer({
      source: new OSM(),
    }),
  ],
  target: 'map',
  view: new View({
    center: [0, 0],
  }),
}));

const changeZoom = () => {
  const view = map.value.getView();

  view.setZoom(4);

  // map.value = map.value;  not working
}

return (
  <div>Zoom: {map.value.getView().getZoom()}</div>
)

Solution

The solution is to introduce the concept of "Trait" to extract features from signals. By default, the feature of a signal is the value's self, and advanced features can be implemented as needed.

API Design

// Default trait
const a = signal(0);  // same as `const a = signal(0, a => a);`

// OpenLayers trait
const map = signal(
	new OpenlayersMap({...options}),
	(map) => map.getView().getZoom()
);
// `map.value.getView().setZoom(3); map.mutate()` for trigger effect;

// Mutable array trait
const arr = signal([], arr => arr.length);
// `arr.value.push(1); arr.mutate()` for trigger effect;

In this way, traits enhance the capabilities of signals, allowing for more effective updates in complex scenarios.

[rschristian]

making it challenging to regenerate the entire map reference when internal properties are updated, thus preventing the signal from updating.

You could just use nested signals, avoiding the need to regenerate the entire object.

const map = signal(new OpenlayersMap({
  layers: signal([
    new TileLayer({
      source: new OSM(),
    }),
  ]),
  target: 'map',
  view: signal(new View({
    center: [0, 0],
  })),
}));

etc.

[anuoua]

This still doesn't work, if it is to take effect, map must explicitly call setView instead of replacing the view object, and openlayers is obviously not declarative.

[anuoua]

I think signals should have a universal solution Trait, rather than letting users make signal-style code modifications themselves (or even unable to modify them), because the actual situation is that complex objects are often highly encapsulated internally, and we have no way to split them Output individual signals.

[rschristian]

This still doesn't work, if it is to take effect, map must explicitly call setView instead of replacing the view object

Point was, you can nest signals to avoid replacing huge/complex objects when you need to update a singular value. How you specifically do this with the APIs you're using is up to you if you don't provide any minimal reproduction of them.

and openlayers is obviously not declarative.

Nothing is obvious, assume we have no idea what "openlayers" is. I certainly don't.

---

Given the above example, you could simply create a thin wrapper around OpenLayersMap to support signal properties, and would be what I'd recommend. Alternatively, you could look into addons like deepsignal which may support what you're after. I don't think the added complexity makes sense here.