Episode 140 · September 15, 2016
Build a reactive multi-user spreadsheet web app with ActionCable and RethinkDB
in app/channels/spread_sheet_cells_channel.rb, set_cell_value here is totally different here than it was there, so let's grab this version, because that looks a lot better than what we've got. That's probably more correct than what we have, when we set the cell value, we are doing a look-- Oh, it's doing the same thing, so it's basically saying: Let's do the upsert that we had before. We're just going to go look up the location, and this example here is just doing the stuff manually, and this is probably getting refactored the upsert later in a commit? Is my guess. Because this is just saying: If we find one, if we look up the first record, and there is one, then we'll update it, and if there's not, then we'll just go create one. My guess is that upsert is what they permanently use, and we can find out by taking a look at their next commit here. There's a refactor, and let's look for upsert here. There we go, there's the upsert, we'll leave it as the upsert and we won't use that one, but let's hop back into the tutorial and take a look at what we've got. Let's take a look at the actual code here. I've refreshed this page, and now we have some things have gotten a little bit out of sync with users again, so I think that it's that the disconnect or unsubscribe isn't firing appropriately for the ActionCable channels, so we're getting these users that are sort of duplicates, that didn't stick around. That's one of those issues that we may have to figure out, where is that a bug at and how do we handle that. Do they just drop off like if a user disconnected, will eventually ActionCable pick up that that websocket connection is dead and then call unsubscribe? It appears to be a bug somewhere in there that we may or may not be able to fix with what we're doing, but we'll have to find out.
This looks to be like it's working reasonably well. We can type into the cells, and we should be able to see that once we hit enter, we should see that that data comes across, and it did not, but let's see what happens when I type in here, and we are looking at the websocket connection, so let's do this. Let's open this up, we're now connected to the two channels, let's type into this box, let's see that the spreadsheet cell channel sets the value, and the value is A, so that worked correctly, and let's see what this one sees, and let's set it to B, and see if this updates. So it did not update, it did not update across the pages, so that's unfortunate, so we still have some bug in here that's not working appropriately
Bug gets fixed off camera
Bug came from me changing the "S" on spreadsheet cells channel, and the names of course did not match up, which meant that the client was not properly connecting to the server side aspect of everything, which should, if we refresh our pages now, we should be able to get this to work in theory... It didn't quite work, but that certainly was one of those things because I did make that spreadsheet_cells_channels.rb and this text should match exactly with this one. We need to make sure that those are kept accordingly, and this shouldn't matter as much, it's just a variable that you set on the client side that you can access that stuff with, so you don't need to change this in order to keep it in sync with that, it's the text here that needs to stay there. What we see is that now we do confirm the subscription, which is good, but we actually didn't receive any of the initial data, which should be saved in the database, so we should see this character here, but we're not seeing that, so the spreadsheets cells themselves may not be saving correctly or something in the database, so we should be able to try to figure out what the
SpreadsheetCell.all is doing. What I'm going to try to do is open up rails console here and see if we have any records in our database, and we do not, so that's interesting, we should have some spreadsheet cells, because they were supposedly inserting those records into the database, and maybe they have not been. It looks like when-- let's go ahead and type into a cell, and let's say: b should be there. Let's make sure that something gets sent over, so we sent over data on the spreadsheets cells channels, the value b and the row and column of 1, 1. So you go zero, one, zero, one and the value of b, and that will get sent over to the spreadsheet cells channel. The green ones are messages that you send I believe, and so this other tab should have received that. We won't be able to look that up, so we'll open up the ActionCable stuff here. When it initializes, it should receive the spreadsheet cells value, so it initally gets the current user value, confirms the subscriptions, and then gets the active user's channel initial value, but we're not getting any initial values from the client. That's interesting, and that seems to point to me that we're not getting any writes to the database when the spreadsheet cells are sent over, so that's pretty interesting, that that is not working, so we now have kind of narrowed this down, and here we go. *Could not execute command from command, message, spreadsheets data. Run time error, could not find a uniqueness validator for the following keys location and value. There's something here that we're running into, and it looks to me that this is what is failing, and it's not saving this to the database. That appears to be our issue, and let's just go and do the opposite of the upsert, and let's just save it as the manual version of this, so let's flip this around to their example, and this is in the spreadsheet channel, so I'll replace that, not do the upsert, we'll do it the manual way for now, and see what happens. If I type the letter "a" here, we should see no errors down here. "Could not execute command" again, though. I believe that that is "Unable to load autoload constant SpreadsheetCellsChannel", and that would be because I did the lower case thing there, so that will fix that, and we can check our logs for anymore errors. This time we'll get the yellow, which means that it was a create, and the green, looks to have done our query on it. That does seem to have work now, and if we type the three into this one, we can go into the other one, and we can see that those characters are now showing up. What we ran into was some weird thing with the upsert, and validations, but I'm not entirely sure, because we didn't write any validations, but this manual way, instead of doing upsert is working, what we'll do is we'll take a look at their code that they refactored and see if what we get then works at all. As you can see, the more that I keep doing this, the more random disconnects that fail to remove the user, so this isn't quite the best situation that you can have. You don't want to have all these failed users to still exist in the database, but that's kind of just the issue with what we've got right now
Transcript written by Miguel
Join 20,000+ developers who get early access to new screencasts, articles, guides, updates, and more.