-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moore/defaulting date range picker to last date #572
Merged
paniclater
merged 7 commits into
master
from
moore/defaulting_date_range_picker_to_last_date
May 9, 2017
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
128f3ee
adding watch script for running locally
e462224
using selected end date as display if available
bf21de0
removing index from key
8eb2539
new lines and removing unused declared variable
894eb04
using selected end date for current date if it is present
f4d5ead
removing npm-watch
23c06d5
removing unused watch script and linked commands
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wondering why you decided to create objects here - what is the
value
key giving you - from what i see you're using it as the key prop, which seems like overkill?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is extremley important to give React keys to elements that are both consistent and unique.
Previously the solution was supplying keys that were unique but not consistent because it relied on the iteration index to create the key:
key={day + i}
.In this case this is not currently causing problems, but it is one of my pet peeves and I wanted to fix it. I couldn't use the day value by itself because then it would be consistent but not unique.
So I created an array of objects with a label and a value. The value for each object is both consistent and unique, so it meets the constraints necessary to be used for a key by React to create iterable elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More background on the importance of unique and consistent keys: facebook/react#1342 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok i'm cool with it. what isn't consistent about relying on the index?
.map
does honor the order of the original array.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the array element changes, or the order changes then it will be a problem. Unlikely here because of the nature of days of the week and the way we're using the labels.
...... but what if we want to introduce dynamic localization to the app, and allow the user to switch between French and English.
Initial render keys would be "S0", "M1", "T2", "W3", "T4", "F5", "S6".
Next render keys would be "D0", "L1", "M2", "M3", "J4", "V5", "S6" <-- one consistent key, 6 inconsistent keys.
Now React is confused, it thinks that it has 6 new elements and one consistent one. In this case the Samedi and Saturday both start with the same initial so perhaps we don't recognize that there's a bug.
Then we add the option to have a longer display for the day of the week, now when we toggle back and forth between languages inconsistent bugs will show up, maybe only 5 elements show up sometimes, maybe "Sat" shows up with the English still in place for the French Saturday, maybe a combination of these behaviors because React will do a good job most of the time, but mess up part of the time since it can't guarantee consistent behavior with inconsistent or duplicate keys. These kinds of bugs could drive a person bonkers trying to tie down.
And this is in a simple example here where there is almost no dynamism. My real concern is people see this pattern and then copy it other places not realizing the potential harm.