Show First, then Maybe Explain
Code is usually pretty good at explaining itself. So it's best to just start writing code while you talking about it, then see if any additional explanation is required. When you fall into the trap of a long-winded explanation before you begin coding, you risk confusing the audience or unnecessarily repeating yourself.
[00:00] First show how, then maybe explain. In this lesson I now show, link the VueRx library and rxjs together by Vue.use, the VueRX plugin and then pass in RX. This way, I've shown you exactly what to do. Too often people get caught explaining before showing, where you would say, "Now I need to link together this VueRx plugin and rxjs."
[00:32] So I'm going to go ahead and type out Vue.use. You can see that that introduction or explanation beforehand is unnecessary, because when you show it, oftentimes simply showing is self-explanatory.
[00:49] Or after you've shown it, you can go into a bit more detail by highlighting a certain piece and saying, "This is the typical approach of registering a plugin with Vue," or something like, "This allows the flexibility to use other Reactive libraries." Save those explanations until after you show how to do it.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!