Updating README to have more background, example usage, and more detailed installation instructions #119
Conversation
|
Hi @maxlindbergh! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
| Then, open your browser and navigate to http://localhost:8000/inspector.html for general debugging, or http://localhost:8000/rn_inspector.html for | ||
| React Native-specific debugging. This allows you to inspect UI components, monitor network requests, and analyze performance metrics directly in | ||
| your browser using Chrome DevTools. |
There was a problem hiding this comment.
| Then, open your browser and navigate to http://localhost:8000/inspector.html for general debugging, or http://localhost:8000/rn_inspector.html for | |
| React Native-specific debugging. This allows you to inspect UI components, monitor network requests, and analyze performance metrics directly in | |
| your browser using Chrome DevTools. | |
| Then, open your browser and navigate to http://localhost:8000/rn_fusebox.html for | |
| React Native-specific debugging. |
| This option continuously rebuilds the project whenever a file changes. It's best suited for active development as it allows you to see changes | ||
| in real time, but it can consume more system resources, especially in larger projects. Use this during iterative work when you need fast | ||
| feedback. | ||
|
|
||
| ```sh | ||
| npm run watch | ||
| ``` | ||
|
|
||
| 1. Build with the default config once: | ||
|
|
||
| This single, non-watched build compiles the project with the default configuration. It’s quicker and less resource-heavy than the watch build, | ||
| making it ideal for testing changes without long-term commitment to resource usage. | ||
|
|
||
| ```sh | ||
| npm run build | ||
| ``` | ||
|
|
||
| 1. Build with the release config once: | ||
|
|
||
| This one-time build optimizes the code for production use. It’s slower to compile and can take significantly more time but results in a stable, | ||
| high-performance version suitable for production environments. Use this when preparing the project for final deployment or release. | ||
|
|
There was a problem hiding this comment.
These bits feel too verbose (AI generated?) — for the target audience, these scripts are self-documenting. Intend to come back and merge this PR, but let's do a pass of the file which removes these.
Summary
I've added some project background to make the goals and capabilities of this project more clear to people not familiar with the codebase. Additionally, I've added an "Example Usage" section to the README so that it is, again, more clear to new users how they can use this software.
Finally, I've added a bit of description to each of the three installation options. I've put in some information on how they differ and when each case should be used.
Test plan
This is purely a documentation change so no real testing is required.