-
- Notifications
You must be signed in to change notification settings - Fork 447
update article to include a more natural way of debugging #934
Conversation
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.
I think this section is getting messy. We have three ways to debug an application and we are showcasing the most primitive and least preferable one. Isn't it better to change the title of the current one to "Logging" and create a new section for debugging with Chrome Dev Tools?
@tjvantoll What do you think about this?
docs/tutorial/ng-chapter-1.md Outdated
| The default way of debugging a NativeScript application is by using the integration with Chrome. You can find more information on the actual steps [here](http://docs.nativescript.org/tooling/debugging). | ||
| | ||
| **Visual Studio Code** | ||
| One of the preffered ways of debugging a NativeScript application is with the [NativeScript extension for Visual Studio Code](http://docs.nativescript.org/tooling/debugging#debugging-with-visual-studio-code). |
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.
preferred
| There are three main paths you can take when you want to debug a NativeScript application: | ||
| | ||
| **Chrome** | ||
| The default way of debugging a NativeScript application is by using the integration with Chrome. You can find more information on the actual steps [here](http://docs.nativescript.org/tooling/debugging). |
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.
I worry that you set readers up for failure by just linking to that page and not walking them through exactly how to use the Chrome Dev Tools. For example, the Chrome Dev Tools only work in iOS if you use the --chrome flag, and that fact is barely mentioned.
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.
I think this will be ok if you mention it after the console.log() example though, because then it’s kind of an aside for readers to check out when they’re ready.
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.
@tjvantoll I don't think we're setting anyone up for failure when we're pointing them to a specific article about debugging. The fact that ios debugging in chrome is working with the --chrome flag is one of the first things, mentioned in the article.
Furthermore, I don't think console.log is actual debugging. On this point, I think more like @etabakov : let's have a logging section, but not call console.log .. debugging.
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.
I think having a different section eventually makes a lot of sense, but I’d be hesitant to add a section that just has two links.
You’ve convinced me that the wording you currently have is worth moving forward with. I just want a bit of text to transition from Chrome/VS Code into the console.log examples and 👍 from me.
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.
Long term I think this tutorial should actually walk the user through running the appropriate commands and teach them the Dev Tools with examples, as @etabakov suggests. The next iteration of the tutorial that Jen & I are thinking through now will almost certainly do that.
Until then I don’t mind mentioning these tools, but I’d kind of like this PR’s wording to be put after the console.log example—just because I think it’ll flow better. Right now it’s a bit weird to say, “here are the best two ways to debug your apps but we’re not going to use them”.
console.log() is basic, but it’s something the reader can do without installing something new, and without having to stop their app from running with Ctrl + C and learning a new debug command with a --chrome flag.
That’s my thoughts at least. If you just replace the sentences below with what you have here I think this should be good for now. (Also remember that there are two tutorials, so there’s a chapter-1.md file with this same wording.)
“The console.log() and console.dir() functions are two of the many tools available when debugging your NativeScript applications. You might want to try out step debugging as you move into more advanced development”
| @tjvantoll I understand what you're saying, but here's what I see.
On this concern: we can just say for the sake of understanding the flow of the application, we can use console.log, which won't be misleading IMO. |
| @Plamen5kov Ok that makes sense. I think as long as you add some wording that makes what you have in this PR flow into the So I’d add something like... You’ll want to check out the Chrome Dev Tools and the Visual Studio debugger as you have the need to step through your JavaScript code or TypeScript code, but for the moment let’s look at how to do some simple logging in your apps. |
| @Plamen5kov It’s “preferred” (two r s) 😉 Update that and 👍 from me on merging this in. |
| my bad |
| This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Update the getting started article to show the normal debugging flow, besides console log.