I’ve been working on my Pomodoro Clock React back-end for a day or so now and I’m stuck on one small aspect of the challenge which is, how do I get my session textarea to update its value after the decrement button is clicked (that’s all the working code that I have at the moment).
I can get the ‘clock’ to display the decremented session length value as I click the minus button, but the related textarea remains static at the initial value of 25.
My component structure is something like this:
+------SessionComponent (contains the decrement button I'm listening to and the text area)
+-------TimeLeftComp (this one reacts properly to the decremented state)
I’m passing a callback function ‘decSession’ from PomodoroComp down to SessionComponent
and it is definitely calling it back each time the decrement button is clicked but though the state is getting updated, it somehow doesn’t re-render SessionComponent’s textarea with the new value.
If anyone has any thoughts on what I could be doing wrong, I would be very grateful to learn.
You shouldn’t be messing with the DOM directly but should be doing it through React. I know it’s a difficult transition when you get into React, but there is almost always a React way to do it. When you start messing with the DOM, you run the risk of breaking React.
Thanks so much! Such a small thing. I will have to remember to refer to the React docs (such as shared by @RandellDawson ) in the future!
For the other concerns you listed.
1- I originally started out with an input field but that was not accepted by the test suite for some reason (I opened an issue about it in github. You can see the failure here:
but weirdly the suite is ok with the textarea having a value attribute. (So I’ll stick to that as my feature list does include the ability to manually type in a session/break length)
2- I didn’t know about the asynchronous setState ! Thanks I’ll look into the method you suggested for logging.
3- the DOM statements to get the session inc/dec buttons is something I planned to use in order to disable these buttons at certain points. I assume that plan is ok?
4- the addEventListener/removeEventListener snippet is directly from the FCC React challenges. I was going to model the handling for the textarea on that snippet. (here’s the link to the FCC challenge that teaches their use:
I’ll take a look at the React docs to see if there is a better way to do this. Thank you.
The button element accepts a property disabled. You should have a boolean in state or passed in as props and use that to set that property. That is the React-y way to do it.
Yes, I think the key press events are a unique situation, and works because you are only listening, instead of writing to the DOM. Still, in general it should be avoided. I think dealing with refs is the only other time you access the DOM directly. Everything else - there’s probably a React way to do it.
Yeah, I remember these same trying-to-learn-the-react-way pains. It’s frustrating and you have to turn your head upside-down, but once you learn the React way, there is a certain elegance to it. It just takes a bit.
React’s synthetic event system is great to use for most interactions you’ll manage on DOM elements. However, if you want to attach an event handler to the document or window objects, you have to do this directly. [emphasis added]
I think the key here is that the keyboard is not managed by React so you need to access it in a non-React way. It’s unfortunate. Randy and I were exploring this the other day and couldn’t find a better method. It’s kind of un-React-y, but for granular keyboard events, it’s how you have to do it for now.