I'm using socket.io in my app, and attaching a socket id to each user after login. I get that info on front end and when I'm trying to emit an event, it creates a new connection so every user gets a new socket id, but the old ids are stored on front end and I'm sending the data to that old ids. What is the solution? (I'm using Angular)
I've tried creating groups, but it really slows down the app because I have to create as many socket groups as every user's friends.
My suggestion to you to solve this problem is to use a unique ID for each user. This unique ID can be created and delivered to the user through rest api. The user puts his ID in an object before every connection to the socket. Your task is this. At the same stage of user connection, create an object for each user. In this object, there are two parameters. The first one is the user ID that does not change, and the second one is the user ID that changes. In this way, you have a list of objects that are inside Each object has two mentioned parameters, it is enough to compare the user using the socket ID loop and implement your logic and operations. Note, at the end of connecting the user, remove the user from the list.
Related
I'm currently working on a ticketing system using Mongo, I've got the basics down, (making tickets, admins responding, etc) but I want to assign a unique ID to allow the user to view the ticket, so /tickets/view/(id), problem is, I don't really know how to assign one, I don't want to use the auto assigned mongo one because it just looks bad on the system, so, how would I assign a ticket with an id that goes up each ticket?
Using: MongoDB Node Module, Express
You can create separate counters collection for sequences, which will store current values.
Then on any insert - query for current value for wanted counter and increment in single operation.
Complete tutorial on that: MongoDB Auto-increment sequence
I'm creating a TODO-list using React.
When the user fills all the fields and presses the ADD button, I want immediately add the item to the list, and then send this item to the server. Then, the server responses with the ID of this item in the database.
The problem is that my app uses item IDs to remember which items are selected at the moment. Also, I want to use IDs in the browser's address bar. But the item ID is being generated on the server, so I cannot figure it out before server responded.
What options do I have?
You can easily add items to a react list without relying on the server-side ID.
If you really need the ID generated by the back-end, I don't think this is possible.
You could of course use some temporary front-end ID (e.g. based on an educated guess) and replace that with the actual ID once the back-end responded, but that would obviously require some obscure bookkeeping and mapping.
It also depends on the way your ID's work. If an item-ID is a combination of the user and the item, the above should be feasible.
Im not sure we are on the same page but u can use local storage to save data and do your local stuff before server response
For a to-do list app, when the user creates a task, the back-end would need to return an ID to identify the task uniquely so that when the user deletes the task later on, the correct task can be referenced in the back-end.
But what if the user deletes the task before the back-end returns with the identifier?
Possible inelegant solutions i thought of:
prevent the user from deleting task until back-end returns the identifier
generate the identifier on the client side (perhaps with the user id + timestamp)
couple the creation and deletion actions together, assigning a temporary id on client side and using Promises to ensure correct deletion. (ugly solution for a Redux framework?)
A "clean" solution which could work well with Redux could be using a generated identifier on the client side.
So an user, create a task id is generated on the client and after is sent using AJAX.
I would recommend disabling the delete button until you get a response back from the server. I know there are more examples out there, but one example of this that I can think of is in the TFS portal. When you create a new User Story, the row gets added to the grid (at the top) immediately. And the api POST is sent to the server. And if you right-click that row immediately, you get a popup menu with a spinner. Then, after a second or so, the front-end gets the response back from the POST, and the popup menu is populated with two items (Add Task and Add Bug).
In game development with SignalR and MVC, I have to manage the player id's.
With MVC all Controllers is re created for each AJAX request so you can't store anything unless you use a database or store it in a cookie.
Does SignalR have any tools I can use for persisting something like playerIds for a game to ease it the situation?
You can't get the connection id's from SignalR, but you can register a ID per user on the OnConnected method. just override that function in your hub.
There might be a simpler way to do it, but one option is to pass the session key to JS, and from JS you can pass that session key (or any other unique identifier) back to the server on every command.
For example, while the user is first connected: OnConnected() -> gets the user unique id from JS and saves it locally to map each user to a unique id(possibly save that id as a group id so you can call send back msgs to that user according to the id).
After you that on each request sent to the hub you can attach the unique ID to it and then you can use it however you like.
I'm pretty sure you can find easier way to define a unique identifier and maybe a more suitable way to save your data in the hub.
Now that I think about it, you should also check this.
I'm adding Mixpanel to my web application and I'm curious about the "process" around what happens when a user transitions from "anonymous" (not logged in/registered) to "identified" (when they register / create an account on the site).
If a user comes in and is new to the site, they get an anonymous UUID (according to the documentation). The documentation also says that Mixpanel can not translate between IDs at this time.
Does this mean Mixpanel is incapable of handling the transition of a non-registered user to a registered user, and keep track of their events from before they became a registered/identified user?
If so, does anyone have experience with working around this? How'd you go about it?
As of December 2012, you can now use the mixpanel.alias method call to alias two ids:
https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias
From the above docs:
John comes to your website, example.com, for the first time. He is
assigned a randomly generated ID (perhaps 123123) by Mixpanel.
Everything he does is associated with that ID.
After clicking through a few pages, he successfully signs up. On the
signup confirmation page, you call mixpanel.alias("john#hotmail.com").
This doesn't actually change his ID - he is still being identified
using the random ID we originally assigned him.
What it does do is add the ID "john#hotmail.com" to a lookup table on
our end. Whenever we see data for "john#hotmail.com", we know to remap
it to 123123, his original ID.
So, you can start calling mixpanel.identify("john#hotmail.com") on all
your pages, and your events, funnels, and retention will all continue
to work perfectly.
There are ways to make this work. But what you are really asking for is a feature called distinct id aliasing, which would allow you to reference one distinct_id ID to another. Unfortunately, we don't offer that right now. This turns out to be a much harder issue than you'd expect due to the unique nature of the data-store we wrote for mixpanel.
In the meantime, I can give you a few strategies to get around this limitation:
When a user first comes to your website, set a distinct id for them which you generate internally. Once they register for an account, reference that distinct_id in your user detail table, and then continue to register subsequent events with that id. Each subsequent time a user auths, use the stored value as the distinct id. Hopefully when they return the cookie will still be around, and you will capture all the events without a hitch.
You could, also, let mixpanel give them an auto-issued distinct_id value, and then grab that at the time of registration by using mixpanel.get_property() then add that to your users table, and use that when you identify them in the future.
But what if they auth from one machine and then come on from another, or a different browser, or from a mobile device? Then the time in between when they hit your site and when they auth they'll be issued a new distinct_id by your site... and there is no way to alias! The solution here is a bit hackier. The only way to get that data is to log those events that were sent before the authentication (maybe server-side) and then send them via HTTP specification to the rest API with the correct distinct_id once the user auths. As long as you keep the correct time stamps, it will all appear correctly, chronologically within mixpanel. If the user never auths, then you can have the logged events time out and send them anyways.
Would either of these work for you?
When a user hits your site, identify them with a unique id and save it in a cookie if they don't already have one, then use the Mixpanel Identify API call to identify them. You can persist the unique id to your database in the user's record once they have registered, so you can re-set it in the case they clear their cookies.
If the user clears their cookies before registering, then you would be out of luck, but that's the nature of this beast and would be an issue anywhere.