I have initialized a Map, set heatRules and then set the data on the polygonSeries by calling polygonSeries.data.setAll().
Everything works fine until I try to set new data on the polygonSeries. When I call polygonSeries.data.setAll() from a separate function, but with new data, the whole map just disappears.
Related
This React with Socket.io.
[canPass, setCanPass] = useState(true)
[example, setExample] = useState('')
useEffect(()=>{
if(socket !== ''){
setCanPass(false)
console.log(example)
if(canPass){
socket.on('connect', ()=>{
console.log(example)
})
}
}
},[socket, example])
This code is inside of a Provider, so the variable "example" will change often.
Initial value of "socket" is an empty string. After the socket is created, the effect will set the listener "connect".
The flag "canPass" avoids setting the listener over and over any time the effect gets triggered.
NOW THE PROBLEM IS: Variable "example" updates normally inside of the Effect, but when the listener function is triggered (let's say server drops and reestablish, or user turn off and on wifi) variable "example" INSIDE of the listener function remains unchanged.
Any ideas how to fix this? Thanks!!
EDIT -> FIXED!
I don't really understand why this question is not that frecuent as I expected. Ok, so, the thing is an event can link more than one listener, and each listener is an instance of the function, it means, it creates a separated scope and the variables inside wont update.
To fix it, I just added another effect, observing the changes of variable "example", ereasing the listener with the method removeAllListeners() and set it again with the new values of "example". And that's it.
When I save a change to the ACL on a PFObject (in this case, making it publicly writeable), the completion block runs successfully but the change is not actually saved to the server. Re-fetching the object, or viewing it via Parse Dashboard, shows that the ACL change is not persisted. In fact, I have verified via server logging that Parse server never even receives a request.
// first fetch an object from the parse server, then...
print("before: \(object.acl?.hasPublicWriteAccess)") // "false"
object.acl?.hasPublicWriteAccess = true
object.saveInBackground { (success, error) in
// confirm that success is true and error is nil
print("after: \(object.acl?.hasPublicWriteAccess)") // "true" - object is updated client-side
// now, re-fetch the same object or check it in Parse Dashboard. It is not saved as publicly editable.
}
When changing an object's ACL, the object itself is not marked as 'dirty', so saving it does not result in a request to the server. You can verify this by checking the isDirty property on the object after changing the ACL.
This is in common with other PFObjects - a change to a pointer property does not mark the parent object as dirty. This is not normally encountered since it is natural to simply save the pointer object itself. Since there is no PFACL.save() function, we can instead re-set the acl property on the object to ensure that it is marked as dirty:
object.acl?.hasPublicWriteAccess = toggle.isOn
object.acl = object.acl
object.saveEventually()
Additional discussion of this can be found in this issue.
I'm working with socket.io. I am having trouble receiving data from the server even though I can console.log() the data (an array of objects) right before I try to emit the data back to the calling client. If I hard code info into the emit, it will display on the client but when I use the dynamically created array of objects, it doesn't go through. My gut tells me its a asyn issue but I'm using bluebird to manage that. Perhaps its an encoding issue? I tried JSON.stringify and JSON.parse, no dice.
Server
socket.on('getClassList', function(){
sCon.getClassList()
.then(function(data){
console.log(data) //data is an array full of objects
socket.emit('STC_gotDatList', data)
})
})
Hard-Coded Expected Output:
classes['moof'] = {
accessList: [888],
connectedList: [],
firstName: "sallyburnsjellyworth"
}
Client
socket.on('STC_gotDatList', function(info){
console.log(info) //prints [] or {}
})
EDIT:
I remember reading somewhere that console.log() may not be printing data at the time the data is available/populated. Could that be it even though im using Promises? At the time I'm emitting the data, it just hasn't been populated into the array? How would i troubleshoot this scenario?
EDIT2:
A step closer. In order to get anything to return, for some reason I have to return each specific object in the 'classes' array. It wont allow me to send the entire array, for the example I gave above, to get data to the client, I have to return(classes['moof']), can't return(classes) to get the entire array... Not sure why.
EDIT3: Solution: You just can't do it this way. I had to put 'moof' inside classes as a property (className) and then I was able to pass the whole classes array.
How is the 'classes' array created?
The problem might be that it is being given properties dynamically, but has not been created as an object, but rather an array.
If you plan to dynamically add properties to it (like property moof), you should create it as an object (with {}) rather than an array (with []).
Try
var classes = {};//instead of classes = []
//then fill it however you do it
classes[property] = {
accessList: [888],
connectedList: [],
firstName: "sallyburnsjellyworth"
};
Also, the credit goes to Felix, I'm just paraphrasing his answer: https://stackoverflow.com/a/8865468/7573546
If one does something on the client like
Foo.insert({blah : 1})
where Foo is a Meteor collection, this actually triggers a Meteor.method call as documented in the last paragraph of http://docs.meteor.com/#meteor_methods that executes code on both the client and the server.
However, let's say I define a method (on client and server) that does the same thing:
Meteor.methods({
bar: function() {
Foo.insert({blah : 1})
}
});
Now, I trigger this on the client with
Meteor.call("bar");
Foo.insert will now be called both on the client and the server as a result of the method. However, how does the client-side invocation of insert know not to call the server again, since it is itself a method?
Moreover, is there a way to call insert on the client side without automatically triggering the canonical server-side latency-compensation call and resulting synchronization? (For why I'd want to do this, see Loading a Meteor client app with fake fire-and-forget data)
The client side one becomes a 'stub'. It has this isSimulation property set that makes it appear as if the data is inserted for latency compensation.
I think if a .method is run on the client the latency compensation is always enabled and it shouldn't enter in the database. So anything running on a client side method would be a 'fake' type simulation
If you try setting this.isSimulation to false you'll get some weird error that shows you that the client side insert starts to throw errors with the insert.
I'm not too sure how to run it in a false simulation. I think you'd have to run it off in some other method var dothis = function() {...} type method.
To do this 'fake fire' & forget and have client side only data, which is what I presume (please correct if I'm wrong so I change the answer) modify the _collection property in your client side method.
e.g if you have
mydata = new Meteor.Collection("something");
function something() {
mydata.insert({..});
}
Modify the method to do this instead
mydata._collection.insert({..});
This will make sure that the data isn't synchronized to the server, yet will have the local collection have this 'fake data'.
Hope this helps!
So, I was attempting to do something like the following:
if(Meteor.isServer){
Meteor.methods({connect_to_api: function(vars){
// get data from remote API
return data;
}});
}
if(Meteor.isClient){
Template.myTpl.content = function(){
Meteor.call('connect_to_api', vars, function(err,data){
Session.set('placeholder', data);
});
return Session.get('placeholder');
};
}
This seemed to be working fine, but, of course, now breaks in 0.5.9 as the Session object has been removed from the server. How in the world do you now create a reactive Template that uses a server-only (stuff we don't want loading on the client) method call and get data back from that Method call. You can't put any Session references in the callback function because it doesn't exist on the server, and I don't know of any other reactive data sources available for this scenario.
I'm pretty new to Meteor, so I'm really trying to pin down best-practices stuff that has the best chance of being future-proof. Apparently the above implementation was not it.
EDIT: To clarify, this is not a problem of when I'm returning from the Template function. This is a problem of Session existing on the server. The above code will generate the following error message on the server:
Exception while invoking method 'connect_to_api' ReferenceError: Session is not defined
at Meteor.methods.connect_to_api (path/to/file.js:#:#)
at _.extend.protocol_handlers.method.exception ... etc etc
Setting the session in the callback seems to work fine, see this project I created on github: https://github.com/jtblin/meteor_session_test. In this example, I return data in a server method, and set it in the session in the callback.
There are 2 issues with your code:
1) Missing closing brace placement in Meteor.methods. The code should be:
Meteor.methods({
connect_to_api: function(vars) {
// get data from remote API
return data;
}
});
2) As explained above, you return the value in the session, before the callback is completed, i.e. before the callback method had the time to set the session variable. I guess this is why you don't see any data in the session variable yet.
I feel like an idiot (not the first time, not the last). Thanks to jtblin for showing me that Session.set does indeed work in the callback, I went back and scoured my Meteor.method function. Turns out there was one spot buried in the code where I was using Session.get which was what was throwing the error. Once I passed that value in from the client rather than trying to get it in the method itself, all was right with the world.
Oh, and you can indeed order things as above without issue.