Skip to content
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

Fix rule violation in sifrr #526

Merged
merged 1 commit into from
Feb 28, 2019
Merged

Conversation

aadityataparia
Copy link
Contributor

@aadityataparia aadityataparia marked this pull request as ready for review February 19, 2019 03:00
@aadityataparia
Copy link
Contributor Author

@krausest Please 🙏

@aadityataparia
Copy link
Contributor Author

aadityataparia commented Feb 19, 2019

@krausest I have a question regarding select implementation:

Before

  • Save selected element directly, and update on change of selected element
    This is a no go according to rule 👍

This PR

  • Loop through all the rows and select row which user selected and deselect any previously selected row.

Question

But will this be considered a rule violation:

  • Save selected row id, and deselect old selected row id and select new selected row id?

This will save loop run time.

@StefansArya
Copy link
Contributor

It seems you have fall in the same hole like me 😄

The purpose of the test is for measuring the framework speed, and not the direct DOM manipulation speed. I think it's okay to save the id of the item, but you must apply any changes with the framework itself..

@aadityataparia aadityataparia changed the title Fix rule violation Fix rule violation in sifrr Feb 19, 2019
@krausest
Copy link
Owner

@aadityataparia You mean like here?
If you save it in the model and use it for initial rendering you should be safe.

@ryansolid
Copy link
Contributor

The only thing I'd consider with such a solution is ensure that swap still works as intended (if the selected row was the one being swapped). I'm not as familiar with if it is different in non-keyed but make sure the functionality works the same. While there aren't testing for all the edge cases you want to make sure your implementation makes sense from how a user would expect interactions to work on a list in which items can be re-ordered and selected at will.

@aadityataparia
Copy link
Contributor Author

aadityataparia commented Feb 20, 2019

@krausest Saving it then,

But there's one thing I noticed that if you save the index of selected row, and then delete a row above this row, and then select some other row, it won't deselect old row since the saved index is not correct anymore. 🤷‍♂️


EDIT:

Can be fixed by adding index decrement logic in delete event listener though. or getting old selected index during select.

On a second note I think i will just find last selected row without saving it to keep expected behaviour in all edge cases.

@krausest krausest merged commit 60c0acf into krausest:master Feb 28, 2019
@krausest
Copy link
Owner

Thanks. Results have been updated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants