5 ms·

I, myself, tried to learn it by generating a sample project with Yeoman. Only to find myself in a project where so many things were already done for me that I c

I, myself, tried to learn it by generating a sample project with Yeoman. Only to find myself in a project where so many things were already done for me that I couldn't make sense of all the pieces that allowed it to work correctly. I would make a couple of changes and if one of them broke something, I was not able to quickly identify what I had done that was a problem. I'd recommend that you go step by step a build a small app from the ground with tutorials.

jdiez17 11y ago
I've had exactly the same experience. I tried bootstrap generators like yeoman, cloned "starter kit" repositories, etc... And they would all have ~1 kilolines of code and a bunch of dependencies. If I tried to do anything (like, say, add react-bootstrap), everything would stop working. The best way is to follow a tutorial and build a small project from the ground up. Stay away from prefabricated solutions until you understand what's going on.
- pluma 11y ago
  IMO, if you need to generate a lot of boilerplate code for your React app, the app is likely incredibly boring and generic, or your code is unnecessarily bloated, or both.
  - jdiez17 11y ago
    It's not just boilerplate code. It's choosing your build system, your hot-reload plugin, whether you want to use jsx or something else, whether you want isomorphic rendering (so that the server will render the initial state of the page, instead of delivering a blank page with a <script> tag), etc.
    - pluma 11y ago
      True, but normally for React that should boil down to an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started) but not much actual code.
      - jdiez17 11y ago
        >an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started) See, but all of that is highly non-trivial and everyone has different opinions.
        tlrobinson 11y ago
        FWIW I independently arrived at exactly the same set of opinions.
  - hanniabu 11y ago
    Can you expand upon this please? On how boiler plate code = boring or bloated....genuinely curious
tommyd 11y ago
Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have found by far the best approach is to start off with just the basics (i.e. React alone), and only add in additional libraries when you start hitting problems you feel could be solved in a more optimal manner (e.g. Redux when state management starts getting messy, then redux-form when you realise form onChange handlers etc. are a bit tiresome to write, etc.). It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter. The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack. One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.

jdiez17 11y ago

I've had exactly the same experience. I tried bootstrap generators like yeoman, cloned "starter kit" repositories, etc... And they would all have ~1 kilolines of code and a bunch of dependencies. If I tried to do anything (like, say, add react-bootstrap), everything would stop working. The best way is to follow a tutorial and build a small project from the ground up. Stay away from prefabricated solutions until you understand what's going on.

pluma 11y ago
IMO, if you need to generate a lot of boilerplate code for your React app, the app is likely incredibly boring and generic, or your code is unnecessarily bloated, or both.
- jdiez17 11y ago
  It's not just boilerplate code. It's choosing your build system, your hot-reload plugin, whether you want to use jsx or something else, whether you want isomorphic rendering (so that the server will render the initial state of the page, instead of delivering a blank page with a <script> tag), etc.
  - pluma 11y ago
    True, but normally for React that should boil down to an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started) but not much actual code.
    - jdiez17 11y ago
      >an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started) See, but all of that is highly non-trivial and everyone has different opinions.
      - tlrobinson 11y ago
        FWIW I independently arrived at exactly the same set of opinions.
- hanniabu 11y ago
  Can you expand upon this please? On how boiler plate code = boring or bloated....genuinely curious

tommyd 11y ago

Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have found by far the best approach is to start off with just the basics (i.e. React alone), and only add in additional libraries when you start hitting problems you feel could be solved in a more optimal manner (e.g. Redux when state management starts getting messy, then redux-form when you realise form onChange handlers etc. are a bit tiresome to write, etc.). It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter. The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack. One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.