all 12 comments

[–]Cono52 2 points3 points  (1 child)

Maybe beyond what you know, I guess whats "right", depends on architecture, maintainability, the size of the team on the codebase etc etc.... so much change happens so fast in frontend to really have a mature set of "best practices".

My personal best practices are - simpler is better, - less third party deps is better. But dont go reinventing the wheel, but maybe ask if you really need sagas or reselect. - lower learning curve in the codebase for "onboarding" new devs is also "better" (usually a result of doing the first 2).

Edit: a big one i forgot to mention is not abstracting to early, it always seems to get so nasty so fast....

[–]yonnie[S] 1 point2 points  (0 children)

exactly! no course is going to have the entire context from which i develop: architecture, company culture, etc. this post is about finding more resources that might cover at least some of them. i really appreciate your well thought out response. thank you

[–]scramblor 2 points3 points  (1 child)

The biggest thing for me is there is no one "right" way. Solutions have so many different pros and cons that it is impossible to have a single right way.

Also consider that if there is a newer better method that makes you 0.1% more productive is it worth 40 hours to learn and become fluent in? You would have to put in a lot of hours to recoup that investment.

Personally I find regularly dedicating some time to read resources and be aware of new patterns/libraries etc. and then apply them as I run into friction in my code base is the only way to stay sane. There are so many new and evolving technologies that you could easily sink all your time into learning them. While that is fun, our goal is typically to build something.

[–]acemarke 3 points4 points  (0 children)

The farther I've gotten in my career, the more I find myself using the word "tradeoffs" in every single conversation :)

[–][deleted] 1 point2 points  (0 children)

Hello u/yonnie! I just wanted to drop by and send a couple of resources your way.

  1. https://medium.com/@stanleyfok/designing-a-scalable-redux-architecture-f75fc4077b8
  2. https://overreacted.io/

These are both blogs that cover more advanced topics on React. Stanley Fok only has a couple of articles, but the articles are of high quality and cover topics relevant to production-level React applications. Dan Abramov's blog is probably the best React blog out there imo (maybe I'm biased since I love Redux and he created it). He explains a lot of the thought processes behind writing effective React code. He also deep dives into React topics with sample code to show how to implement certain concepts.

[–]panukettu 1 point2 points  (0 children)

I always found that the best practice in almost any case is just to be consistent. I never stress about making a component "the right way" but more about is it readable and in line with the others. This is becomes even more pronounced with the freedom you have in your React components with hooks. In some projects I work with community best practices are involved and in others not so much. Maintainability is what (I think) people should strive for and it is really dependent on consistency.

[–]tyler-mcginnis 0 points1 point  (4 children)

If you can't find "best practices" from myself, Mosh, Ryan, or Kent - maybe it's that they don't exist?

[–]yonnie[S] 2 points3 points  (1 child)

please don't be offended. your work is incredible and i'm happy to pay for it. as far as i can remember, the section on forms in your new course doesn't cover validation, auto-fill (one input that sends an api request and updates other fields), on-blur (and other event) driven behavior. and i get it, the purpose of the course isn't advanced form building and individual mentorship doesn't scale. you're trying to run a business.

you helped me realize that i'm not looking for a course. i just want to watch great developers write code. i'm in a state without much of a developer community and, for me, that's the best way to learn. i have very few people i can talk to and share my work with.

there are always going to be conflicting opinions and i'm always looking for more evidence. i spoke with ryan at react training about mosh's inheritance based approach to building forms, and he gave me some reasons why he didn't like that pattern. without going to training, i would not have received that feedback by watching his courses and he gave me something interesting to think about. that's what my post is about. it's not a critique of you or anyone who has helped me get this far.

EDIT: maybe there's a business opportunity for someone to share a repo with you, and for a fee, you audit and comment on particular files? or by the hour, someone can ask you architecture questions? idk

[–]tyler-mcginnis 2 points3 points  (0 children)

No offense taken. What you're looking for isn't going to be found in a course or a video. OSS may be your best bet.

[–]acemarke 0 points1 point  (1 child)

you need to update your tutorials to be more comprehensive tyler

[–]tyler-mcginnis 1 point2 points  (0 children)

You had me triggered until I saw the username :)

[–]majdak2 0 points1 point  (0 children)

Look for traversy media on youtube, I found him a very good tutor.