I am using the latest #stomp/stompjs package in react and it appears to be not working as described so I was wondering if anyone know what was going on.
When I do stompClient.subscribe() I expect only 1 message from the backend. But I normally get an empty object first "{}" and then then the callback goes off again I then get the expect json string. Sometimes I get a 3rd callback with the same json string. I know the page is being redrawn with the new data by react, but I would not think this would cause the callback to go off a second time. Also, this behavior seems to be only for large json string responses. Small response status json objects never returned multiple times in the callback (just the {} object the first time). My workaround was to have a flag that I sett when I do the send command and then is set to false when I get a valid response back. Any extract responses are skipped not saved in the useState hook so react doesn't redraw again.
The second thing I see is sometimes the wrong response is received by the callback. The bookmark paths would be like /location/read and /location/readBL but the response for /location/read would be read by the readBL subscription callback sometimes. This happens 1 out of 10, but I don't understand why it would doing that. The workaround I did is to have the main object key have different words like {camera: {}) and {cameraBL: {}} and see if the object key matches in the expected key in the callback, otherwise skip it.
I assume react is somehow responsible for all this. So, has anyone seen this in their stomp code and know what's going on?
I have inserted flags or filtering to workaround the problem. I have not seen any description of these problems on the web and the stomp home page doesn't talk about any of this.
Related
I have the following problem:
I have a document with data in firestore. I collect the data from that document and show it on the screen, everything is perfect. But, if I add data or modify it, how can I get the new data at the moment the document has been updated, without continuously checking if there have been changes? Since it would exceed the firestore reading limit. That is, it receives a kind of notification that there is new data, checks it and updates itself. I've tried with a state variable(useState) inside a useEffect but I can't find a way to make it work.
I hope you can help me.
first at all try to make a get right after your create or update action on the document.
If you don't want to do that, you can read this part of the documentation of firestore and try to create a custom hook calling it directly on the useEffect (in order to get every update in the lifecycle).
I wanted to get your opinion on something.
I'm trying to understand how a subscription works. however, I couldn't find a way to pull an array of objects in a subscription. for example, if I use createMany, I can not return all the result via subscription.
The second issue is if I return a single item for example if it's a new item, I have to "manually (air quote)" add that item to the list that is already displayed. But this feels to me I don't actually display real-time true data.
So my question is using something like
useEffect(() => {
// refetching original query when subscription is triggered
refetch();
}, [updatedNotificationData]);
would there be any downside like hitting up the server more than I should? let's say every time there is a refetching happens I might be pulling thousands of notifications (I know there is caching but still) or is there a better way to deal with bringing new data.
Also, I tried adding subscribed data to the original list but for some reason react adds 2 of the same item every time.
Thanks in advance if you can give me in the right direction.
if I use createMany, I can not return all the result via subscription.
That shouldn't be a problem if you define the return type of the subscription as array.
type Subscription{
onChange:[ObjectType]
}
It would allow you to avoid fetching again but updating cache can get a bit complicated.
Also, I tried adding subscribed data to the original list but for some reason react adds 2 of the same item every time.
In case you are using the the subscribeToMore method it's not really reacts fault but the way how the updateQuery method works: github issue regarding this.
My workaround was to subscribe via the useSubscription hook and handle the cache modifications inside the onSubscriptionData callback apollo documentation and also setting the useQuery hooks skip option once I get the data so it wont query on each rerender.
I'm trying to implement a search box, where every time user types something, the search result will show on the page.
JS fiddle link : https://jsfiddle.net/wsypeter/dh59Lwr2/47/
here is the code for fetching the data and setting the state
basically as I type abc the response might came back in order abc ab a and the result is finally a which is wrong.
How should I fix this ? I know one way is to use debounce, but I think it will still run into issue if the response timeout is super long.
This is an interview question, the interviewer said canceling pending request or debouncing is not the solution he's looking for.
For the above example , there must be 3 requests going out and the final result should be the response of the last request.
How do I do it?
You could use debounce for this kind of issue.
Only after the user finished typing and hasn't typed anything else for e.g. 500ms then you call the api.
Using https://github.com/reactjs/express-react-views as a starting point, I can successfully get server-side rendering/client-side mounting working. Problem I have is the size of the page once react has stamped data-reactid's over the state passed to renderComponentToString.
The object itself is a JSON payload from a server-side async call and comes in around 80KB. I pass this as is to renderComponentToString and the resultant page is over 20MB!
At this stage I'm thinking I could switch to renderComponentToStaticMarkup and take the hit client side for the first diff when I next update the state but wondering if there is a smarter solution here (props vs state?). Looking at the very clever react-quickstart (https://github.com/andreypopp/react-quickstart) I see the async state is effectively completely decoupled from the normal component lifecycle and therefore doesn't suffer from this issue however there's a lot of moving parts here and I'd rather come up with something more lightweight based on https://github.com/reactjs/express-react-views but with the necessary moving parts in place for client-side mounting to work.
Thoughts? Am I doing something wrong here?
I've resolved this for now:
The serialised payload for client-side mount was actually being rendered in the react render method, which was a noob error on my part. This was done rather than stringifying it and passing it down in a piece of non-react markup, which is what I should have done from the start.
This is my use case: I call fetch on a collection and receive a JSON from my server yet I have an error flag. This will always trigger the success flow, and I can detect the error by 2 means:
In my parse method - which is ugly.
By not using the success option, and using the Deferred's Done callback to check for the error. This is ugly as well since I have to call parse myself afterwards.
This would be solveable if Backbone had a validate function on collection but it doesn't...
Any suggestions?
EDIT: I know there's a way to do it by supplying my own Sync method but I got a bit lost there...
good question.. I'm not sure it's so bad to work with the parse method. It's name doesn't fit but it's all you've got in the natural path of the code and I guess you can just return an empty list without breaking anything.
The question to me is what is the cause of the error? If it's, say, a permissions thing (or some other error covered by the http protocol), you could return an error code from the server which should trigger your error callback..