Save player names as the user changes them #57

cheshire137 · 2017-03-11T16:49:17Z

Fixes #51.

I discovered a problem with our logic for storing a player_hero_id on player_selections: it doesn't let us update the hero selection for a given player in a composition at a particular map segment. So I split the key into player_id and hero_id and put a unique index on map_segment_id + composition_id + player_id so we disallow having the same player on multiple heroes for the same point in a given composition. Discussed with @rewinfrey to confirm my thinking.

Another gap in our data model was we didn't allow for the team organizer to set a player name without first having made a hero selection for that player. So I could enter all my players' names and reload the page, and none of them would be persisted. I added a composition_players table to tie players in a particular order to the composition.

This replaces the throttle-debounce npm package with react-debounce-input since it's built to work with React and I was able to get it working with the normal value and onChange properties you should use on an input.

This also refactors CompositionsController#save so it makes use of a new CompositionSaver model. This pulls a lot of logic out of the controller and makes things easier to read.

Here's the new functionality; note the page reload in the middle and how the data fills back in:

What if the user starts typing a player name before making any hero selections? We want to save "zioncross" as the first player for that comp, but the only thing tying a player to a composition is the player_selections table, which requires a map segment and a hero selection. No longer!

cheshire137 · 2017-03-11T18:35:40Z

Tests are passing:

% be rspec
..........................................................

Finished in 3.04 seconds (files took 2.65 seconds to load)
58 examples, 0 failures

npm run style also runs cleanly.

rewinfrey

This is a great start @cheshire137! I'm marking as approved as I don't want to hold you up if you are happy with this direction, but I left some thoughts and suggestions. There appears to be a bug in the position assignment for new CompositionPlayer records at the moment.

rewinfrey · 2017-03-11T21:10:09Z

spec/models/composition_player_spec.rb

@@ -0,0 +1,33 @@
+require 'rails_helper'
+
+RSpec.describe CompositionPlayer, type: :model do


Is there a reason you prefer this style, rather than describe CompositionPlayer do?

This is what RSpec generated when I did rails g model CompositionPlayer. I don't have a preference really.

rewinfrey · 2017-03-11T21:25:42Z

app/controllers/compositions_controller.rb

+      hero_id = player_selection.hero_id
+      player_name = player_selection.player.name
+      result[hero_id][player_name] ||= []
+      result[hero_id][player_name] << player_selection.map_segment_id
    end

    result
  end


In get_map_segment_ids, I think we're doing more work than we need to. If I'm following this correctly, it looks like the JSON builder views for CompositionsController are only interested in the heroes for which a player has been created. If that's the case, we should be able to reduce the composition.player_selections into the result hash:

composition.player_selections.includes(:player).reduce({}) do |result, player_selection| hero_id = player_selection.hero_id player_name = player_selection.player.name result[hero_id] ||= {} result[hero_id][player_name] ||= [] result[hero_id][player_name] << player_selection.map_segment_id result end

If there's another reason we're requiring all Heroes to be populated first in the result hash, please ignore this. I'm not seeing the reason for that though based on the return value from the JSON request.

If there's another reason we're requiring all Heroes to be populated first in the result hash

For the convenience of the JSON views, so we don't have much logic in the views. When I tried your code, I got a undefined method '[]' for nil:NilClass error on last_composition.json.jbuilder:25 I believe because @map_segment_ids[hero.id] is nil so we can't grab @map_segment_ids[hero.id][player.name] from it. We could do a check in the view "is there a hash at hero.id in map_segment_ids?", but that's logic I'd rather have elsewhere, like the controller.

rewinfrey · 2017-03-11T21:26:17Z

app/controllers/compositions_controller.rb

-      player_name = player_selection.player_hero.player.name
-      result[hero_id][player_name] = player_selection.map_segment_id
+      hero_id = player_selection.hero_id
+      player_name = player_selection.player.name


Might be nice to add a helper method for player_name on PlayerSelection in the same spirit as hero_id.

If we end up using this more than once, I'll do it!

rewinfrey · 2017-03-11T22:30:40Z

app/models/composition_player.rb

+  def set_position
+    return unless composition
+
+    self.position ||= composition.composition_players.count


I'm not sure we want to memoize here. This seems to have adverse affects on the position calculated for new players added to a composition. When memoized, the CompositionPlayer records created for me always have a position of 0. Was there a specific goal you had in mind with memoizing here?

The goal wasn't memoization here but rather to set a default value only if the caller didn't explicitly pass a position. I want the caller to be able to override the position, and that's what this allows: if position is already non-nil, it doesn't get set to the default value of how many other players are in this composition.

the CompositionPlayer records created for me always have a position of 0

Were you using the same composition for each new CompositionPlayer you created? If not, I'd expect it to always be 0.

There's a model test, sets position, that shows the position defaults to something >0 as more players are added the composition.

rewinfrey · 2017-03-11T22:31:13Z

app/models/composition_player.rb

+      errors.add(:composition, 'has maximum number of players already.')
+    end
+  end
+end


It would be lovely to add some tests for CompositionPlayer 🙇

There are! See https://github.com/cheshire137/overwatch-team-comps/blob/persist-player-names/spec/models/composition_player_spec.rb.

rewinfrey · 2017-03-11T22:34:22Z

app/models/composition_saver.rb

+    end
+
+    true
+  end


I feel like this is pretty complex to read. There is a mix of declarative and imperative code here that makes the conditional branching a bit much to load into the brain (or maybe that's just how I feel on a Saturday) 😛 ?

I think one thing that would help in this context is to consider treating players as a select list rather than a text field in the team composition react component. Then we could give the user an option for create player, which would allow us to take care of player record creation independently of team composition record creation. I think that also would be a nice feature to have regardless for users, so they always have a select list of their previously created players when they switch to a new map to create a new composition. What do you think?

I feel like this is pretty complex to read.

I agree! I feel like this is an improvement over the logic being in the controller, but I think we can continue to improve this model.

so they always have a select list of their previously created players

I agree! The idea had come up before of autocompleting player names based on past compositions, or when you start a new composition you get text fields already filled with your past player names. Just moving to select menus sounds easier, though. I'll file an issue!

cheshire137 added 7 commits March 11, 2017 10:09

Refactor controller via new CompositionSaver

69a5938

Permit specific params for composition save

723a209

Update composition save to require ID to update existing player

4868824

Split player-hero association on PlayerSelection

7618ad3

Whoops change players, heroes relations on Composition

6e14759

Allow updating hero on player selection

837ac33

Update controller and request specs

a9df96d

cheshire137 self-assigned this Mar 11, 2017

cheshire137 added 14 commits March 11, 2017 11:03

Set map on composition if different

8a49ac4

Allow updating just player name

8bbf22f

400 response for bad player ID

2f41508

400 response for bad composition ID

a8d3576

Persist CompositionPlayer on save

b242777

Allow only 6 players per composition

85a7a2b

Test creating a player in a composition

077d0d9

Require player be in composition for PlayerSelection

615dc34

Test can create player in new composition

9eb5c00

Allow creating new player on new comp by map ID

e35c81d

Hook up front end to persist player names

be40abc

Swap throttle-debounce for react-debounce-input

5c2bbcc

Whoops same hero can be on many map segments

93045e8

cheshire137 requested a review from rewinfrey March 11, 2017 18:35

cheshire137 added RQ01 Document hero choices RQ02 Save team composition RQ06 User signup not required labels Mar 11, 2017

rewinfrey approved these changes Mar 11, 2017

View reviewed changes

Merge branch 'master' into persist-player-names

17b0669

cheshire137 mentioned this pull request Mar 12, 2017

Use select menu for player selection, adding new players #60

Closed

cheshire137 merged commit 039e711 into master Mar 12, 2017

cheshire137 deleted the persist-player-names branch March 12, 2017 14:45

cheshire137 mentioned this pull request Mar 26, 2017

Let a team organizer create players #16

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Save player names as the user changes them #57

Save player names as the user changes them #57

cheshire137 commented Mar 11, 2017 •

edited

Loading

cheshire137 commented Mar 11, 2017

rewinfrey left a comment

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017 •

edited

Loading

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017 •

edited

Loading

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017

rewinfrey Mar 11, 2017

cheshire137 Mar 12, 2017

		@@ -0,0 +1,33 @@
		require 'rails_helper'

		RSpec.describe CompositionPlayer, type: :model do

+                  end
+                  true
+                end

Save player names as the user changes them #57

Save player names as the user changes them #57

Conversation

cheshire137 commented Mar 11, 2017 • edited Loading

cheshire137 commented Mar 11, 2017

rewinfrey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheshire137 Mar 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheshire137 Mar 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheshire137 commented Mar 11, 2017 •

edited

Loading

cheshire137 Mar 12, 2017 •

edited

Loading

cheshire137 Mar 12, 2017 •

edited

Loading