Proposal: Exposing granular component update APIs beyond Signal changes

[SuiltaPico]

Hi everyone,

I've been working with the framework in scenarios involving a large number of component instances, and I've noticed that component rendering is always tied to Signal changes. While Signals are a powerful tool for reactivity, I believe there's room for optimization when dealing with granular updates in high-instance-count situations.

Currently, if I want to directly trigger an update for a specific component instance, I see two primary options:

1. Individual Signals per Instance: Create a separate Signal for each component instance and then iterate through them to trigger updates. This approach feels inefficient because it introduces a significant memory overhead due to the large number of Signals, even if many of them are rarely used.
2. Centralized Signal: Use a single, central Signal to trigger updates across all component instances. However, this leads to a large number of listeners being attached to the central Signal initially, also resulting in substantial memory consumption.

The Problem:

Both of these approaches introduce unnecessary memory usage. We're essentially forced to use the full weight of the Signal mechanism even when we only need to trigger a targeted re-render of a specific component.

Proposed Solution:

I propose that we explore exposing lower-level component update APIs that are not solely dependent on Signal changes. Signals would remain a primary way to drive reactivity, but we could offer alternative methods for more granular control.

Potential Benefits:

• Reduced Memory Footprint: By avoiding the creation of numerous Signals or a heavily subscribed central Signal, we can significantly reduce memory usage, especially in applications with many component instances.
• Improved Performance: Directly triggering updates on specific components could potentially be more performant than relying on a broad Signal change that might trigger unnecessary checks or updates in other components.
• Greater Flexibility: Developers would have more fine-grained control over when and how components update, allowing for more optimized rendering strategies in specific use cases.

I believe that exploring these options could lead to significant performance and memory improvements, especially in large-scale applications.

Thanks!