ui: Small EventSource additions #5978
Conversation
1. EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
`(configuration, source) => source.close()`. Order of arguments could
potentially be switched at a later date.
2. BlockingEventSources now let you pass an 'event' through at
instantation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.
```
new BlockingEventSource(
(config, source) => { /* something */ },
{
cursor: 1024, // this would also come from a cache
currentEvent: getFromSomeSortOfCache(eventSourceId) //this is the new bit
}
);
// more realistically
new BlockingEventSource(
(config, source) => { return data.findSomething(slug, config) },
getFromSomeSortOfCache(eventSourceId)
);
```
|
Potentially used a word that can mean different things here 😬 When I say unfreeze, I mean 'take it out of the cache'. Currently once you leave a page with an EventSource and it is closed, it is placed in a cache to be 'unfrozen' when you next visit that page. We do this so we keep a track of the Currently when we 'cache' EventSources we cache the entire thing, so the So, this change makes it easier to create a new EventSource with the state of another, therefore you can just cache its state as a JSON blob rather than the EventSource itself. As well as it being slightly easier, I just prefer it, it means I shouldn't need to concern myself with any type of specialised cache just for this (so say I'd made the state of the
Previously we still did it immediately, just you had to set that up manually from outside the EventSource. It doesn't make sense that you have to set this up manually. So now, if you add a currentEvent to the initial configuration object, it will immediately fire that for you, as if it had come from the backend API. That way when you visit a page, take the EventSource out of the cache, the page immediately renders as if it had received the response immediately. As a result of this change you have to do less to make this happen. I suppose the TLDR is these are all just tiny tweaks to make it ever so slightly nicer to work with. P.S. Let me know if I've not covered anything and I can expand here or offline. |
|
Cool cool, thank you for the added color, this makes sense now. Also generally +1 to caching the smallest and simplest required state. |
1. EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
`(configuration, source) => source.close()`. Order of arguments could
potentially be switched at a later date.
2. BlockingEventSources now let you pass an 'event' through at
instantation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.
```
new BlockingEventSource(
(config, source) => { /* something */ },
{
cursor: 1024, // this would also come from a cache
currentEvent: getFromSomeSortOfCache(eventSourceId) //this is the new bit
}
);
// more realistically
new BlockingEventSource(
(config, source) => { return data.findSomething(slug, config) },
getFromSomeSortOfCache(eventSourceId)
);
```
1. EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
`(configuration, source) => source.close()`. Order of arguments could
potentially be switched at a later date.
2. BlockingEventSources now let you pass an 'event' through at
instantation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.
```
new BlockingEventSource(
(config, source) => { /* something */ },
{
cursor: 1024, // this would also come from a cache
currentEvent: getFromSomeSortOfCache(eventSourceId) //this is the new bit
}
);
// more realistically
new BlockingEventSource(
(config, source) => { return data.findSomething(slug, config) },
getFromSomeSortOfCache(eventSourceId)
);
```
1. EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
`(configuration, source) => source.close()`. Order of arguments could
potentially be switched at a later date.
2. BlockingEventSources now let you pass an 'event' through at
instantation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.
```
new BlockingEventSource(
(config, source) => { /* something */ },
{
cursor: 1024, // this would also come from a cache
currentEvent: getFromSomeSortOfCache(eventSourceId) //this is the new bit
}
);
// more realistically
new BlockingEventSource(
(config, source) => { return data.findSomething(slug, config) },
getFromSomeSortOfCache(eventSourceId)
);
```
1. EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
`(configuration, source) => source.close()`. Order of arguments could
potentially be switched at a later date.
2. BlockingEventSources now let you pass an 'event' through at
instantation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.
```
new BlockingEventSource(
(config, source) => { /* something */ },
{
cursor: 1024, // this would also come from a cache
currentEvent: getFromSomeSortOfCache(eventSourceId) //this is the new bit
}
);
// more realistically
new BlockingEventSource(
(config, source) => { return data.findSomething(slug, config) },
getFromSomeSortOfCache(eventSourceId)
);
```
EventSources now pass themselves thorugh to the run function as a
second argument. This enables the use of arrow functions along with the
EventSources API
(configuration, source) => source.close().Order of arguments could potentially be switched at a later date.
BlockingEventSources now let you pass an 'event' through at
instantiation time. If you do this, the event will immediately be dispatched
once the EventSource is opened. The usecase for this is for 'unfreezing' cached
BlockingEvents. This makes it easier to provide a cache for
BlockingEventSources by caching its data rather than the entire
BlockingEventSource itself.