René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"extend streaming resource with {status} capability","articleBody":"### Which @angular/* package(s) are relevant/related to the feature request?\n\ncore\n\n### Description\n\nAfter playing around with the new streaming resource in 19.2.0-next.0 I thought about different usecases where I would like to use this.\n\nFirst: the resource is only in \"Loading\" state when a new request is emitted until the promise resolves with the first (signal of) value. Afterwards, when a new value is emitted the resource will just update. This is fine!\n\nBut what if the implementation \"knows\" when it is fetching a value?\n\nExample 1: Polling\n\nImagine some API which doesn't support streaming, so it has to be polled. The \"poller\" would then know when it is going to fetch the next value (even on the same request).\n\nExample 2: Retry\n\nImagine some streaming resource implementation which automatically retries after an error occured. It will then know when it is \"Reloading\".\n\n### Proposed solution\n\nExtend the type of the signal with\n\n```ts\n{ value: T }\n| { error: unknown }\n| { status: ResourceStatus.Loading | ResourceStatus.Reloading }\n```\nWhen the signal of the streaming resource emits a \"status\" the `Resource\u003cT\u003e` transitions to the given state (I don't think the other `ResourceStatus` values make sense here).\n\n### Alternatives considered\n\nCurrently the implementation would have to encode the (re)loading information into its value and that can't be populated to the `Resource\u003cT\u003e`'s status.","author":{"url":"https://github.com/flensrocker","@type":"Person","name":"flensrocker"},"datePublished":"2025-01-25T09:37:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/59712/angular/issues/59712"}