Documentation module would benefit from kick-off files

Question

Documentation module would benefit from kick-off files

EdmundsEcho opened this issue 7 years ago · 6 comments

Great work on ps. I tried to be selective in what I pulled from this repository e.g., just the generateComponentsData.js file to then build alongside with your work. I quickly got caught pulling in one file after the other to get the first to compile. In the end, pulling all if the files with the final results already coded. If you have a bare min set of files to get started that help me exploit the benefits of the course. Thanks. - E

Answer 1 · 2017-08-14T21:12:21.000Z

Great point - I can appreciate how that would be useful. You're saying you didn't want to have to go through the Documentation module to set up the environment, correct? You'd rather just download a completed environment so you can skip ahead to the next module?

Just want to assure I'm understanding your use case.

Answer 2 · 2017-08-15T23:10:43.000Z

Correct.

I'm going through Creating Reusable React Components (call it CRRC - on pluralsight). I worked through a couple of your other titles including creating a dev environment. I tried initially to tweak/adjust the configuration from one of your other titles to work on CRRC. The available resources on the ps CRRC website only had pdfs (it seemed); this github only has the completed project (or near so as best I can tell not having completed the course). It would be great to provide a starting point that includes a working config and outline of the directory structure (optional but helpful). That way we can opt to build the code ourselves along the way. The CRRC course is useful at many levels including consolidating some of the most recent methods for coding components. Finally, you do seem to make efforts to reference/contextualize across your other titles; where feasible it might be useful to qualify how this configuration differs from what you did earlier (as a side-note).

Answer 3 · 2017-08-16T14:20:25.000Z

Quick question/idea: I'm also a big advocate for testing along the way. I wonder how the documentation might not include the code required to test the basic functionality and/or provide templates for something more involved? What do you think?

Answer 4 · 2017-08-22T02:37:29.000Z

Since this course uses create-react-app, testing is supported out of the box using Jest. I showed how it works in the testing module. This repo is merely a compliment to the course and isn't intended to stand on its own, so that's why I've omitted docs on testing and other details. I assume the user is going watch the course. Does that make sense?

Answer 5 · 2017-08-24T17:45:51.000Z

Hi Cory, Bottom line, your courses are complete and well thought out. The only "?" - I don't know what to call it, even to say "opportunity" isn't fair because it implies you have not been already proactive in the design of your course material. All I can say is that I followed one of your courses and we used chai + mocha; the scripts were in a directory you called buildScripts. In ps-react we are naming the same directory scripts and will be testing with Jet (I have not made it to testing yet). Configuration is a pain point AND even when I was trying to apply/integrate what I've learned at different points in the ps learning path AND with the same instructor :-) Also, I recognize the github is a bonus. It's helpful and needed though. One other big pain point out there, is the lack of a coherent explanation of how webpack uses and depends on NODE_ENV being set and being able to read it's value AND for two different reasons: (a) to control +/- dynamically the output of webpack; in this case, NODE_ENV can be set and read by our webpack scripts (b) when using webpack to read and translate libraries to provide auto-complete support while we are coding what will be the eventual input to webpack; in this situation we ALSO need to set the NODE_ENV value prior to our webpack scripts are fired up. This requires we export NODE_ENV to register our production/development status in the user environment such that it propagates and is in scope for all of the shell's child processes; a child process that is eventually our webpack scripts. This process.env scope is something that our webpack scripts can only read from but cannot set. If we don't set/export the NODE_ENV in our shell/terminal, webpack will not load as required to function/inform the auto-complete. Is that clear? Believe it or not, I have seen virtual yelling matches online that mocked a front-end programmer for his lack of understanding of system and environment variables... Propagating/echoing this FYI might help. If you agree and think your audience might benefit, please feel free to use this content anyway you like. - E

…

On Mon, Aug 21, 2017 at 10:37 PM, Cory House ***@***.***> wrote: Since this course uses create-react-app, testing is supported out of the box using Jest. I showed how it works in the testing module. This repo is merely a compliment to the course and isn't intended to stand on its own, so that's why I've omitted docs on testing and other details. I assume the user is going watch the course. Does that make sense? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKuXaXSPmU4SfMACEBDkp8a1ScAghbSwks5saj7pgaJpZM4O2l1O> .

-- Edmund Cape, PhD MBA (917) 715-8299 edmund.cape@gmail.com

Answer 6 · 2017-08-25T01:58:18.000Z

Hi Edmund - Thanks so much for the thoughtful advice! I agree that these are confusing topics so I'll certainly keep these areas in mind for future updates/courses.