Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialRichard Verbraak
7,739 PointsDo you have to add the if statement for the nextLi? (code inside)
ulList.addEventListener("click", (event) => {
if (event.target.tagName === "BUTTON") {
if (event.target.className === "remove") {
let li = event.target.parentNode;
let ul = li.parentNode;
ul.removeChild(li);
}
if (event.target.className === "up") { //this moves the element up
let li = event.target.parentNode;
let prevLi = li.previousElementSibling; //first get the previous sibling
let ul = li.parentNode;
if (prevLi) { //if there's a previous list item
ul.insertBefore(li, prevLi); //insert a li before the previous one
}
}
if (event.target.className === "down") {
let li = event.target.parentNode;
let nextLi= li.nextElementSibling;
let ul = li.parentNode;
if (nextLi) {
ul.insertBefore(nextLi, li); //you switch the next list before the other list
}
}
}
});
Ignore the comments and not cleaned up code (yet) but why is the last if statement at the bottom needed?
If I would remove the if statement it would still send the item down, and because there isn't one after, nextLi would be null aka false. So why even bother to add the if statement?
I do get an error message about failing to execute the insertBefore which is logical and if I do add Guil's if statement as in the code above, I won't have the error anymore. Which I totally get.
1 Answer
Steven Parker
231,269 PointsIt sounds like you already "totally get" the reason for the "if" statement. It prevents executing the "insertBefore" when the first argument would be null and cause an error. It's the graceful way to handle the last list item.
However, the thing that I would change is the assignment of "ul" before the test. It's not needed anywhere but inside the conditional block, and since it's only used once the variable "ul" can be elminiated completely:
// let ul = li.parentNode; <- not needed except inside the "if"
if (nextLi) {
li.parentNode.insertBefore(nextLi, li); // don't create "ul", use paretNode directly
}
Richard Verbraak
7,739 PointsRichard Verbraak
7,739 PointsSo it's just a way of neatly ''tying it up" and nothing less? And yes I believe refactoring is coming a bit later in this lesson but thanks for showing what and how to refactor.
Steven Parker
231,269 PointsSteven Parker
231,269 PointsRichard Verbraak — It's more important than just being "tidy". Allowing errors to occur could cause unexpected behavior on some browsers even if your own is tolerant of them. Error conditions that can be anticipated should always be avoided, or caught with exception handling techniques (perhaps something you will learn in a different course).
And if your question has been answered, you can mark it solved by choosing a "best answer".
Happy coding!