I'm not quite sure how to explain this, but here is a picture that could help explain the issue that I seem to be facing.
As you can see, I have a SharedNotificationsModule and a SharedConversationsModule, these are totally separate to one another and each contain their own state files.
I am importing the SharedNotificationsModule into my SharedHeaderModule as this is where the majority of notification related content will be.
However, if I navigate to the ConversationsPage and the LOAD_CONVERSATIONS_SUCCESS is triggered my previous notifications slice is being overwritten.
This isn't only happening on the LOAD_CONVERSATIONS_SUCCESS action, this happens on other pages but some times the action that get's the user or the action that get's a users profile (when navigating to the users profile page).
I'm not sure what/if any code you would like to see, but just let me know what you want.
I finally figured this out now, turns out that I had forgotten to add a default to the switch in my notificationsReducer. The default now just returns the existing state.
default:
return state;
Related
From: next/link
You can see that the <Link> component from next/link enables client-side transitions and link prefetching, which are great features, but maybe not for all cases.
Please see the caveat I've run into. Let's say I have the following pages:
Home - Some landing page with a nav bar
Latest - Here I can see my latest posts
Admin - Here I can add more posts
The Latest page from the example above uses getStaticProps with revalidate. Something like:
export const getStaticProps : GetStaticProps<HomeRoute> = async () => {
const preloadedState = await getPreloadedState();
return({
revalidate: 1,
props: {
preloadedState
}
});
};
In theory, after 1 second, it should send the last stale response for the next request and trigger a new static regeneration to be served for the subsequent requests. After 1 second, the process repeats and you get fresh data at least after every second, which is pretty much immediately.
Now, see the caveat I've run into with next/link:
User lands on the Home page. There is a Link on the nav bar pointing to Latest. That link will be prefetched by next/link.
In some other browser, an admin goes to the Admin page and adds one more post (which should appear on the Latest page at some point).
Now user clicks on the Latest page link. The new post is not there.
Clicks on Home again. And clicks again on Latest. New post is still not there and never will be.
The transitions in this case are blazing fast, which is nice. But from my experience so far, I think that that user is locked inside a version of my website where the new post will never be available, because that 1st prefetch happened during a time where the new post didn't exist.
The only way that user will ever see the new post is if he/she presses F5 to do a full website reload. And it might be necessary to refresh twice, because the 1st one might return the previous stale version while triggering the regeneration for the next one.
I mean, what is the workaround to this issue? Should I not use next/link for pages that contain any dynamic data? Should I just use normal <a> tags?
UPDATE
From: https://nextjs.org/docs/basic-features/data-fetching#statically-generates-both-html-and-json
From the excerpt above, we can see that indeed, client-side transitions will not trigger a page regeneration, because they'll not call getStaticProps. They only fetch the pre-built JSON object for the page to use as props.
AFAIK, it means that you'll be locked to the version of the page that existed when you first visited the website. You can go back and forth and nothing in the pages would change, because the JSON data is probably cached on client anyway.
PS: I've tested this (like I've mentioned in the question above) and this is exactly what happens.
So how to workaround that? I would like for users that keep an open tab of my website to be able to get updates for the pages when they navigate from one page to the other.
A POSSIBLE SOLUTION
Set some kind of idle time counter, and if the user gets like 10 minutes of idle time (it means that they left the tab open). Whenever he comes back and do some action, I could refresh the whole website to make sure they get the new version of the pages.
Has anyone faced that problem before?
I've posted this very same question in several forums and this is the response I've got:
It seems what you described is true. next/link caches results in the client-side and your visitor will not fetch a revalidated result out of the box unless there is a full-page reload.
Depending on the likelihood of content changes, you might want to use <a> instead or you can look at some client-side content reload strategy that kicks in after mount and query data source for updated content.
Given that fact, I'll stick to using next/link and client-side transitions. But I'll also use something like a setInterval() to do a full website reload from time to time, so I'm sure my users will keep getting revalidated pages eventually.
I am using a webapp2 in GAE, when I called self.redirect to some page like below:
self.redirect(some_url)
which returned a page looks like cached, I have to refresh/reload the page so that I would get latest data.
Is there any cache setting for webapp2? or I have to set some properties for response of that page? Please advise.
In my project I've fixed that by adding time.sleep(0.1) just before the self.redirect('someurl') call.
Not sure if it is a best way to solve the problem, but pages started to show most recent info.
Edit: beware of consistency issue
Check out #Lindsay answer. Using time.sleep(0.1) might give you the expected result in a local environment, but you cannot trust it in a production environment. If you really need results to be strongly consistent, use an ancestor query, not time.sleep(0.1).
My guess is that this is happening because the earlier page is updating an entity that is then being accessed on the later page by means of a non-ancestor query. A non-ancestor query provides eventual-consistency rather than strong-consistency, so the problem is not that the page isn't being refreshed, but that it's showing what the data looked like before the update was completed. When you refresh, or add a call to time.sleep(), you may be providing enough time for the datastore to catch up, especially during testing. However, in production, your sleep may not be long enough in all cases, and the same is true of a page-refresh.
If you check your application and find out that you are using a non-ancestor query, and therefore your problem is indeed eventual-consistency vs strong-consistency, a Google search will show you that many pages discuss that topic; here's one: https://cloud.google.com/developers/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore#ftnt_ref1.
The simplest solution seems to be to create an entity group and use an ancestor query, though that comes with a possible performance hit and a limitation of one update per second per entity group.
Got the same problem I have done a trick which is not good but helped me anyway. Called a temporary view file then did html redirect:
<meta http-equiv="refresh" content="0.5;URL='/'">
Hope it helps. any one with a better answer?
Do you call return immediately after the self.redirect(some_url)? It may be falling through to other code that renders a page.
Steps to reproduce in our application:
Log out.
Clear the cache.
Reload the page.
Log in.
Actual: You stay on the front page.
Expected: The application opens.
Our main template shows the app if a user is logged in (specifically, {{#if currentUser}}). Otherwise, it shows a splash page where the user can create an account and log in.
We're using the {{loginButtons}} helper.
Would this be a use case for Meteor.flush()? How would I get that to trigger upon user login? Meteor.autorun()?
Could it be that the logic isn't actually in a template you've defined but rather in the index.html itself? I could see how that might cause issues if it hasn't been broken out into some sort of front page logic template from which you call the other templates. Just an idea.
There were a couple things that led to a solution here.
I restructured my front page template to take {{loggingIn}} into account. Before, I was only using {{currentUser}}.
I made sure I wasn't setting Session variables in template helpers, especially not those where I was also getting them in other code paths. This explains why the issue felt like a race condition and only happened with a "cold cache" as I put it.
Also, the reason the view wasn't changing was because of errors preventing it from doing so. So it was a symptom, not the actual problem (although I did need to improve the template conditions a bit).
Currently, I have an asp.net web application that links to another page. The enduser clicks on a link which response.redirects to a validation page. This works correctly they finish with the validation page and this response.redirects them back to the initial page that they started on. The specific problem is that when the user is brought back to the initial page any work that they had previously completed is now gone (aka filling in textboxes/dropdowns etc.). I have been reviewing the best way of making sure this doesn't continue to occur and everything seems to be pointing to saving the view state of the page prior to redirecting to the validation page, and then reloading this view state upon coming back to the initial page. Although, I fell like using response.redirects will not allow this to occur. Now if the end user was just clicking the back button then this would work. Basically, my problem is keeping the data that my enduser input present on the initial page. Any thoughts/ideas/suggestions will be greatly appreciated. Please go easy as it is my first post here. Thanks.
I am not sure whether or not this will solve your issues but long time ago there was an idea to store the ViewState on the server and restore it on demand.
http://www.codeproject.com/KB/applications/persistentstatepage.aspx
This came at a price of turning of the validation. I remember I tweaked it a little bit:
http://netpl.blogspot.com/2007/11/persistentstatepage-with-event.html
I hope you'll find it useful.
I will suggest looking at this article: 9 ways to persist user stat
Which state choice is really up to you and what your application requires. Its a little old (2003) but a good guide to user state.
I have a custom multi-step form that I add to certain node type content via hook_nodeapi. It is working great, with one exception.
During testing, I've found that when I am in mid-form (say, step 2 of 6) and update the node in another browser tab, my form reverts to step 1 when I try to proceed to the next step. Similarly, when an AHAH event occurs, I get an error and the form disappears altogether. The error suggests there is a problem with retrieving the form from cache after a node update, as it's not able to retrieve the form parameters.
Have you encountered this behaviour before, and/or do you have any suggestions on how I might go about fixing it? It isn't a huge problem as these nodes likely won't be updated too often on the production side, but it would still be a significant nuisance to those it does affect.
Edit: Thanks for your response. Unfortunately I can't contain this form within a block. It must be within the node content itself. Upon further testing I noted that other users thankfully aren't affected. It is only the user that updates the node while in mid-form that is affected. As this is extremely unlikely to happen on the production site, the impact of such an occurrence would be minor, and I have no time at the moment to explore this further, I'm going to move on with this behaviour unexplained for now. But if anyone can point out why this is occurring, I'd appreciate it.
Well, have just tried your situation based on multistep form described here - http://zgadzaj.com/basic-drupal-multipart-form-example-with-previous-and-next-buttons - but put in the block and displayed on node page, and even if I edit this node in a different tab, I still can navigate between all form steps on the original tab, keeping all already submitted values. So I'd say it all probably depends how your form is being built...