joshleblanc / view_component_reflex

Call component methods right from your markup
http://view-component-reflex-expo.grep.sh/
MIT License
288 stars 27 forks source link

Component state not preserved between page reloads #18

Open bduc opened 3 years ago

bduc commented 3 years ago

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 ?

joshleblanc commented 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.

sebastianiorga commented 3 years ago

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?

joshleblanc commented 3 years ago

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

joshleblanc commented 3 years ago

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.

sebastianiorga commented 3 years ago

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)

recording

joshleblanc commented 3 years ago

I'm not seenig this behaviour in 3.1.7

5KknHkV9W9

Do you have an MVCE I can look at?

sebastianiorga commented 3 years ago

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.

joshleblanc commented 3 years ago

The flash is turbolinks.

I'll start testing with cookiestore this evening

joshleblanc commented 3 years ago

@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.

sebastianiorga commented 3 years ago

Fair enough, I'll switch development mode to the redis store. Thank you for looking into all this!