feat: default to vanilla JS instead of React #387
Conversation
|
Let's remember this page in docs, too |
| console.log('Error: ', e); | ||
| process.exit(1); | ||
| } | ||
| }; |
There was a problem hiding this comment.
I removed this function, since I believe this is the default behavior. If JavaScript encounters an error, it stops executing and logs the error.
| command: '$0 <projectDir>', | ||
| desc: 'create a new blank react project', | ||
| builder: (yargs) => yargs | ||
| .option('projectDir', { |
There was a problem hiding this comment.
Listing this as an option made it show up in the help output alongside --rust and --vanilla options, which is not correct. I've moved a streamlined version of this .command right into the yargs block at the bottom.
| .option('contract', { | ||
| desc: 'language for smart contract', | ||
| choices: ['assemblyscript', 'rust'], | ||
| default: 'assemblyscript' |
There was a problem hiding this comment.
I've renamed this from asc to assemblyscript everywhere for the purpose of making the --help output easier to understand without insider knowledge.
|
|
|
and readme here: |
|
worth combing through the Google Slides to see if those need to be changed, too |
|
and here: |
`create-near-app` is being updated to default to vanilla JS in near/create-near-app#387 there have been some other changes lately, too, and this updates the docs to match additionally, I doubt it makes sense to have an entire dedicated page for `create-near-app` in the docs, so I've removed it. This sets us up to have duplicated docs here and in the `create-near-app` README. This moves us closer to a single source of truth and makes the docs easier to maintain.
near/create-near-app#387 removed the --vanilla flag and made vanilla JS the default; we can remove this flag here
|
Thanks, @mikedotexe! I created draft PRs in the repos you noted above (see linked PRs above), except for the one in
I also looked through a bunch of our slides and updated where needed. Not sure I caught all of them, but I caught a bunch in the workshops we'll likely do over & over, such as the intros to Rust and AssemblyScript. |
|
@ashleynear @potatodepaulo I know y'all didn't scope this for near/devx#220, but I did it now anyhow because I think it's a necessary prerequisite to having someone complete near/bounties#17 (add a Vue template to create-near-app) or similar bounties in the future. Why? If you were a community contributor, would you feel confident suggesting changes to the shape of the flags used by But with this change, adding |
near/create-near-app#387 removed the --vanilla flag and made vanilla JS the default; we can remove this flag here
* fix: update test with create-near-app assumptions the structure of create-near-app changed in v1 and we need to change this test to match the commit that changed it is here: near/create-near-app@7ab9ae3 * refactor: remove obsolete --vanilla flag near/create-near-app#387 removed the --vanilla flag and made vanilla JS the default; we can remove this flag here * Fix CI * Update expected output from view call Co-authored-by: Jane Degtiareva <jane.degtiareva@gmail.com>
Our user testing showed that not everyone was excited about defaulting to React. Furthermore, defaulting to Vanilla and changing the argument syntax makes it easier to support new frontend templates (and other smart contract languages) down the road.
Our user testing showed that not everyone was excited about defaulting to React.
Furthermore, defaulting to Vanilla and changing the argument syntax makes it easier to support new frontend templates (and other smart contract languages) down the road.