5 ms·

Debugging React has been pretty painless. Errors show up in the console, step through with Devtools if things get weird... One of the great things about React

Debugging React has been pretty painless. Errors show up in the console, step through with Devtools if things get weird... One of the great things about React is It's Just Javascript (technically CoffeeScript in my case). One thing that has made things a bit easier is React Developer Tools: https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en https://chrome.google.com/webstore/detail/react-developer-to... It gives you a Devtools tab that looks like the DOM Inspector, but it's the React component tree. I've mostly found it helpful when dealing with abstract components (components that render other top-level components rather than DOM components). I can't see your code so unfortunately I can't give you more specific advice, but in general, I've found that if you feel like you have too much code, you're probably overcomplicating things. This holds true in React, and (in my experience) programming in general. Then again, if it's just a big form, that could be the problem. Big forms aren't usually a great UX anyways, so maybe consider breaking that up into more discrete pieces - but I'm basically talking out of my ass at this point since I don't know your situation. Hope this helps though! Also happy to answer any questions over email (in my profile). I'm far from a React expert but always glad to lend a hand.

aethertap 12y ago
Thanks for the tips! I haven't tried the developer tools, which sound like a crucial piece of the puzzle. Without them, the debugging experience had a lot of "Why is there nothing on the screen and nothing in the console?" moments. I did a lot of old-school printf debugging with it because of that. As far as the big form, I agree it's typically not what you want. I'm working with a pharmacist on a workflow specific to her particular location though, and this is what we think will meet her needs the best. It's one of those tools that you'll use 500 times a day, where taking advantage of rapid input via muscle memory trumps any kind of new-user friendliness. The over-complication mostly seemed to come from the need to have the form auto-save to an alternate backup location periodically. I've actually just about got her convinced to try some vim-inspired keybindings with it (speaking of strange, but efficient, UX), but we'll take it a step at a time on that front.

aethertap 12y ago

Thanks for the tips! I haven't tried the developer tools, which sound like a crucial piece of the puzzle. Without them, the debugging experience had a lot of "Why is there nothing on the screen and nothing in the console?" moments. I did a lot of old-school printf debugging with it because of that. As far as the big form, I agree it's typically not what you want. I'm working with a pharmacist on a workflow specific to her particular location though, and this is what we think will meet her needs the best. It's one of those tools that you'll use 500 times a day, where taking advantage of rapid input via muscle memory trumps any kind of new-user friendliness. The over-complication mostly seemed to come from the need to have the form auto-save to an alternate backup location periodically. I've actually just about got her convinced to try some vim-inspired keybindings with it (speaking of strange, but efficient, UX), but we'll take it a step at a time on that front.