Open bduc opened 3 years ago
Yeah, that was an intentional decision. I don't see any reason we can't make it an option to persist state, though.
I'll take a look at this when I get a chance, thanks.
There's a slightly buggy aspect to this. I've got a rails 6.1 app, latest versions of SR/VCR, 2 routes setup so I can click between them, one has the counter component, the other an empty page.
Using the Counter example in dev mode, if I increment it up to 10, click on the other page's link then click on the counter page link, the counter flashes 10 then updates to 0(the default) but after one increment click it updates to 11. It either needs to truly reset the state or initialize with it. My dev mode is using the default session_store CookieStore
.
In prod env, with config.cache_store = :redis_cache_store
and config.session_store :cache_store
doing the same flow, the old value flashes but then resets to 0 and incrementing it starts at 0 so it seems to correctly reset the component state.
I assume the old value flashing is turbolinks loading the cached page html client side before the server sends the new page html. The dev mode bug is probably CookieStore related?
That's interesting. I think both of those pages should be using the same session, so they should have the same state with the current implementation. Shouldn't be showing 0 at all. Must be a problem with the component initialization, I'll take a look at this
Can you try 3.1.7 @sebastianiorga
The state should reset whenever a component is mounted now. So in your example, when you increment the counter, then navigate to the same page on another tab, it should increment from zero.
With a different tab I think it already worked. Using 3.1.5, if I increment in one tab, ctrl-click the link to the same page the new tab is starting from 0, no flash or anything and increments correctly.
The bug shows up when I navigate to a new path in the same tab. See gif below.
Gem versions VCR 3.1.7, VC 2.25.1, SR 3.4.1(technically the pause_observer branch, but it's the same on 3.4.1)
I'm not seenig this behaviour in 3.1.7
Do you have an MVCE I can look at?
If I change my development.rb to
config.cache_store = :redis_cache_store
config.session_store :cache_store,
key: '_session',
compress: true,
pool_size: 5,
expire_after: 1.year
everything works like in your gif. Seems like this is an issue only when using the CookieStore
.
That being said, even in your gif there is still a brief flash of the old value(just the first time, if you click back and forth a few times the correct default value is displayed) when you go back to the Local state
page, though that's not that big a deal.
The flash is turbolinks.
I'll start testing with cookiestore this evening
@sebastianiorga I took a look at this.
You're going to run into more problems than just inconsistent persistence with the cookie store. Cookies have a max size of 4KB, and it doesn't look like rails serializes/deserializes objects coming in and out of the store the same way other adapters do, so any objects you have in state come out as hashes.
I wouldn't consider the cookie store as viable session store for VCR.
Fair enough, I'll switch development mode to the redis store. Thank you for looking into all this!
Hi, I'm trying to put this fantastic thing into practice, replacing my view_component's with state in the session with view_component_reflex.
Is it on purpose that the state of the component is reinitialized when the page reloads and there is already state in the session ? I also checked on the expo page and the local_state demo has the same behavior: if you reload the page the counter start at 0 again ?