(patch)
* add a spinner during the blitz new version check
* improve the ux on blitz new upgrade
* Apply suggestions from code review
Co-authored-by: Aleksandra Sikora <alexsandra.sikora@gmail.com>
* Add package manager prompt to blitz new
* make pnpm the default package manager in blitz new if pnpm is installed
* add yarn flag in blitz new
* add form flag in blitz new
* refactor the upgrade part in blitz new
* in blitz new when looking up for a globally installed blitz first try pnpm, then yarn, then npm
* replace yarn with pnpm install in commands/new test
* Fix custom-server hot reload on first run (patch)
We want to build custom-server, but only run watch if specified.
* Fix custom server - do not build twice in prd
BLITZ_APP_DIR is set to the appropriate values when running:
- Blitz routes CLI command
- next start
- next dev
But not when running a custom server. The above should fix it. (patch)
* don't throw an error if checkYarn is null or checkYarn.stdout is null or undefined
* make sure to check if this version is less than the latest version
* fix forgotpassword test template, sync auth example tests
* revert to ensure monorepo tests work
* revert to original password and index tests
* remove merge reference
* fix merge issue
* Quirrel recipe: start > dev, double quote command
* add Suspense boundary
* Update packages/generator/templates/app/app/pages/_app.tsx
* send "blitz.js" in x-powered-by header
* Update test for powered-by-header
Considered making the test check to see if anything at all was present, but not needed for our use case right now
* Update test to check for x-powered-by
* update favicon to be orange in new blitz apps
* Support both NEXT_PUBLIC_ and BLITZ_PUBLIC_
Make webpack take environment variables prefixed with either NEXT_PUBLIC_ and BLITZ_PUBLIC_ to the frontends environemtn variables
* Revert "Support both NEXT_PUBLIC_ and BLITZ_PUBLIC_ "
This reverts commit 9760bcb70d.
* define parser type, add argument to resolver zod
* Add tests for argument, no value
* add ability to parse async, and tests
* Fix lint issue
* use fn overloads, return promise conditionally
* Update packages/core/src/server/resolver.ts
* fix linter issue
Co-authored-by: Roshan Manuel <Roshan,manuel@angelic-group.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
(major)
* fix: Change all user facing references of next.js to blitz.js
* fix: fixed instances of next.js in unit test files
* fix: fixed instances of next.js in integration test files
* fix: next.js regex in test integration 9
* fixes
* fix
* fix a test
* fix dynamicrouting test
* more test fix
* bump
Co-authored-by: Brandon Bayer <b@bayer.ws> (patch)
* Added trailingslash support for API endpoints.
* Accidentally RM'd actual condition it was meant to be based upon.
* simplify integration test
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Update types.d.ts
Just use reference to nextjs typings. It is already includes such things as `module.scss` and more
* Update packages/generator/templates/app/types.d.ts
Co-authored-by: Brandon Bayer <b@bayer.ws>
Co-authored-by: Brandon Bayer <b@bayer.ws>
As noted in this PR: https://github.com/blitz-js/blitzjs.com/pull/421 blitz requires a SESSION_SECRET_KEY when deployed to prod. This change will make it easier for new devs to deploy instantly to render using this template.
* don't throw an error if checkYarn is null or checkYarn.stdout is null or undefined
* make sure to check if this version is less than the latest version (newapp)
* fix forgotpassword test template, sync auth example tests
* revert to ensure monorepo tests work
* revert to original password and index tests
* remove merge reference
Co-authored-by: Roshan Manuel <Roshan,manuel@angelic-group.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
* use decodeURIComponent to fix bug where slashes in url path were not being converted from hex
* handle decodeURIComponent(undefined) case (newapp)
* fix type error
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Update next to version 10.0.9
* fixes
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Proxy "blitz export" to "next export" (minor)
* Add "static" example
* Fix manifest missing
* fix tsc error
* Fix version of Blitz for static example
* Use preconstructs monorepo build tooling
* Add type that static example needs for compilation
* Run "next export" on ".next", not on ".blitz/build/"
* Remove forgotten console.log o.O
* Don't change type of nextBuild[manifest]
* Update static example Blitz version
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Adding initial recipe for LogRocket (recipe)
* Remove NodePath import since it is not used. Simplifying call to LogRocket.identify to just pass in the userId as the first parameter and sessionData object as the second parameter.
* Add comment to LogRocket config
* Fixing copy/paste comment for transform files step in LogRocket recipe
* Removing check for useRouter in blitz import as we are no longer using it. Removing variable declaration node, that is unused.
* Changing directory for logrocket.ts helpers from utils to integrations.
* allow the session to be accessed within the passport strategy
* add callback to test types
* add environments type file to auth example
* replace environments type file with inline types
Co-authored-by: Brandon Bayer <b@bayer.ws> (minor)
* Adding recipe for styled-components.
* Adding all changes to _app.tsx. Adding basic util/theme.ts file to hold the theme and global styles. Still need to finish codeshift changes to _document.tsx
* Adding changes to _document.tsx
* Fixing var name
* Incrementing version of styled-components recipe.
* Adding back try/catch and sheet.seal()
* Adding babel plugin for styled-components recipe.
* Solve TODOs
Co-authored-by: Simon Knott <info@simonknott.de>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* try to fix windows EPERM issue
* comment
* fix test
* bump test wait time
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Update next to version 10.0.7
* fix
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Clear console
* Removed clearConsole on blitz start
* Moved no-clear-console to blitz.config.js
* Changed imports
* increase default jest timeout to 10000 for server env
Co-authored-by: Brandon Bayer <b@bayer.ws> (minor)
* Add initial parameter to useSession hook to remove flickering if session is loaded via server side.
* Use better naming.
* Update packages/core/src/supertokens.ts
* fix and cleanup types
Co-authored-by: Brandon Bayer <b@bayer.ws>
* add `SimpleRolesIsAuthorized<RoleType>` type so `session.$authorize()` can type check the roles AND update new app template accordingly (minor)
* fix type
* (newapp) upgrade prisma to 2.16 and change `@prisma/cli` to new `prisma` name
* fix cli
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Update next to version 10.0.6
* type fixes
* big refactor to fix resolve config
* more refactor and fix
* fix jest
* fixes
* fix import
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* fix blitz new for people without global git config
* adjusted test to reflect changed git parameters in blitz new
* Update packages/generator/src/generators/app-generator.ts
* Update packages/generator/test/generators/app-generator.test.ts
Co-authored-by: Brandon Bayer <b@bayer.ws>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Update `blitz generate` templates for Prisma 2.15 AND update newapp/examples to Prisma 2.15
* fix type error
* actually fix that TS error
* fix
* more fix
(minor)
* Update next to version 10.0.5
* few fixes
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Add regression example
* Dont rewrite file-imports that end in /pages or /api
Only import directory imports (where import "someDir/pages" actually means "someDir/pages/index.js").
Closes#1646
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
I just tried blitz.js the first time and wanted to play around with the recipes.
Installing the tailwindcss recipe broke the app due to to css import errors displaying a prompt to also install postcss which solved the issue, so I guess it makes sense to fix at the recipe level?
* Apply transform to file-pipeline
* Rewrite writer to correctly report that file has been deleted
* Debug windows issues
* Fix up action changes to run all tests
* Fix bad merge
* Fire ready event as string down pipeline
* Fire ready event always
* Add comment
* Close stream in test
* Debugging: Try skip live watching test
* Don't create the watcher unless we are in watch mode
* Update agnostic-source.test.ts
* Wait for close promise to end before starting other test
* Debug watcher limit issue
* Try increasing watchers
* Try increasing watchers after dependency installation
* Only increase watchers in linux
* Only increase watchers in linux
* Fix bad os selection
Co-authored-by: Brandon Bayer <b@bayer.ws>
* Allow api folder inside global pages folder to accommodate plain next app
* Removed warning about nested API routes
* Revert useless change
* Add test cases and fix up algorhythm
* Remove unnecessary function
* Allow Stage to have a ReadWriteStream so we can test it easily
* Add normalize to paths to account for windowz hackrz
* Remove comment
* Tidy up normalize code so it is clearer
* Extract out synchronizer
* Alter codeowner of synchronizer
* Move agnostic input to pipeline
* Fix up manifest writing
* Abstract away Manifest ready output
* Extract rules from pipeline
* Move rules to live within server as they are blitz specific business concerns and depend on next.js
* Fix up auto import error
* Fix up incorrect Manifest type path
* Create DEBUG logger
* Pass configuration to rules not synchronizer
* Rename configureRules function
* Tidy up file transformer API
* Simplify configuration
* synchronizer -> file-pipeline
* Rule -> Stage
* Use nullish coalescing now we have it in TS
* Add documentation for file-pipeline
* Update docs
* Move image and remove outdated diagram
* Update Docs
* Refactor: Remove pipeline folder
* Update readme with a PR suggestion
* Update wait on scripts
* Add Documentation
* Update docs
* Add display package
* Extract out log to display package
* Remove server references from packages that dont use it
* Remove incorrect dependency
* Fix up incorrect module field
The Blitz core members take this CoC very serious. All members, contributors and volunteers in this community are required to act according to the following Code of Conduct to keep Blitz a positive, growing project and community and help us provide and ensure a safe environment for everyone.
The Blitz community
## When Something Happens
If you see a Code of Conduct violation, follow these steps:
1. Let the person know that what they did is not appropriate and ask them to stop and/or edit their message(s).
2. That person should immediately stop the behavior and correct the issue.
3. If this doesn’t happen, or if you’re uncomfortable speaking up, contact Brandon Bayer ([Twitter](https://twitter.com/flybayer) | [Email](mailto:b@bayer.ws)).
When reporting, please include any relevant details, links, screenshots, context, or other information that may be used to better understand and resolve the situation.
The core members will prioritize the well-being and comfort of the recipients of the violation over the comfort of the violator.
## What We Believe and How We Act
- We are committed to providing a friendly, safe and welcoming environment for everyone, regardless of age, body size, culture, ethnicity, gender expression, gender identity, level of experience, nationality, personal ability or disability, physical appearance, physical or mental difference, race, religion, set of skills, sexual orientation, socio-economic status, and subculture. We welcome people regardless of these or other attributes.
- We are better together. We are more alike than different.
- Our community is based on mutual respect, tolerance, and encouragement.
- We believe that a diverse community where people treat each other with respect is stronger, more vibrant and has more potential contributors and more sources for ideas. We aim for more diversity.
- We are kind, welcoming and courteous to everyone.
- We’re respectful of others, their positions, their skills, their commitments and their efforts.
- We’re attentive in our communications, whether in person or online, and we’re tactful when approaching differing views.
- We are aware that language shapes reality. Thus, we use inclusive, gender-neutral language in the documents we provide and when we talk to people. When referring to a group of people, we aim to use gender-neutral terms like “team”, “folks”, “everyone”. (For details, we recommend [this post](https://modelviewculture.com/pieces/gendered-language-feature-or-bug-in-software-documentation)).
- We respect that people have differences of opinion and criticize constructively.
- We value people over code.
## Don'ts
- Don’t discriminate against anyone.
- Sexism and racism of any kind (including sexist and racist “jokes”), demeaning or insulting behaviour and harassment are seen as direct violations to this Code of Conduct. Harassment includes offensive verbal comments related to age, body size, culture, ethnicity, gender expression, gender identity, level of experience, nationality, personal ability or disability, physical appearance, physical or mental difference, race, religion, set of skills, sexual orientation, socio-economic status, and subculture. Harassment also includes sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, inappropriate physical contact, and unwelcome sexual attention.
- On Slack and other online or offline communications channels, don't use overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.
- Don’t be mean or rude.
- Respect that some individuals and cultures consider the casual use of profanity offensive and off-putting.
- Unwelcome / non-consensual sexual advances over Slack or any other channels related with this community are not okay.
- Derailing, tone arguments and otherwise playing on people’s desires to be nice are not welcome, especially in discussions about violations to this Code of Conduct.
- Please avoid unstructured critique.
- Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
- Sponsors of Blitz are also subject to this Code of Conduct. In particular, sponsors are required to not use sexualized images, activities, or other material which is not according to this Code of Conduct.
## Consequences for Violations to this Code of Conduct
If a participant engages in any behavior violating this Code of Conduct, the core members of this community will take any action they deem appropriate, starting with a gentle warning and then escalating as needed to expulsion from the community, exclusion from any interaction and loss of all rights in this community.
## Decisions About Consequences of Violations
Decisions about consequences of violations of this Code of Conduct are made by this community’s core members and may not be discussed with the person responsible for the violation.
## For Questions or Feedback
If you have any questions or feedback on this Code of Conduct, we’re happy to hear from you.
## Thanks for the Inspiration To
- [Hood.ie](http://hood.ie/code-of-conduct/)
- [WeAllJS](https://wealljs.org/code-of-conduct)
[Read the Code of Conduct at Blitzjs.com](https://blitzjs.com/docs/code-of-conduct)
[Read the Contributing Guide at Blitzjs.com](https://blitzjs.com/docs/contributing)
We're so excited you're interested in helping with Blitz! We happy to help you get started, even if you don't have any previous open-source experience :)
## Notes For Core Team
<br>
### To Publish a new NPM Package under `@blitzjs/` namespace
### Blitz is a Community Project
1. cd into the package directory
2. Run `npm publish --tag danger --access public`
-`--access public` is required because scoped packages are set to private by default
Blitz is built by and for the community. There's no large company sponsoring development. So all community contributions are very appreciated!
### Syncing Next.js Fork
<br>
1. Run `yarn push-nextjs`
- If it fails with an error of `git-subrepo: Can't commit: 'subrepo/nextjs' doesn't contain upstream HEAD:`, then run `yarn push-nextjs --force` (see https://github.com/ingydotnet/git-subrepo/issues/530)
2. Create new git branch for the upgrade
3. In the forked repo (https://github.com/blitz-js/next.js), run:
1.`git pull`
2.`git fetch --all`
3.`git merge v10.2.0` (change the version to be the version you are updating to)
4. Run `rm -rf examples && git add examples`
5. To resolve conflict with their version for a path, like docs, run this:
-`git checkout --theirs docs && git add docs`
6. Resolve all merge conflicts and complete merge
7. Run `yarn` and make sure all builds complete
8. Run `yarn lint` and fix any issues
9. Commit all changes to finish merge
10.`git push`
4. Run `yarn pull-nextjs`
5. Run `yarn`
6. Run `yarn manypkg check` and optionally `yarn manypkg fix` to fix any issues
7. Under `nextjs/`, run `./scripts/check-pre-compiled.sh` and commit the changes
8. Run `yarn build:nextjs`
9. Run `yarn lint` - fix any issues
10. Run `yarn build` - fix any issues
11. Run `yarn test:nextjs-size` and update tests if there are any failures
12. Open PR and fix any failing tests
13. Update any references to nextjs in new code including imports like `next/image`, etc.
14. Any doc updates needed?
15. Merge PR
16.`yarn push-nextjs`
### Our Codebase is a Garden
#### Troubleshooting
The Blitz codebase is like a community garden. There's a lot of beautiful plants and vegetables, but it won't take long until you find some weeds! When you find weeds, please remove them :) Minor refactoring is always encouraged. If you'd like to do some major refactoring, it's best to first either open an issue or check with us in Slack. Most likely we'll agree with you.
##### yarn lint - Failed to load parser
<br>
Caused by invalid version of `@babel/eslint-parser`. `7.13.14` is a working version. I think it may be an incompatibility between this version and the version of eslint?
### First Things First
1. New to open source? take a look at [How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github)
2. Familiarize yourself with the [Blitz Code of Conduct](https://github.com/blitz-js/blitz/blob/canary/CODE_OF_CONDUCT.md)
3. Join the [Blitz Slack Community](https://slack.blitzjs.com)
<br>
### Weekly Contributors video call
Every week Blitz contributors meet in a video call to discuss progress and ideas.
The contributor video call is mainly for those contributing or want to start contributing. However anyone is welcome to join and listen!
#### The timezone
We are literally all over the globe, so the weekly contributors call alternates timezones every other week to accomodate different regions
- Even weeks of the year: **Tuesday at 1am UTC** (Note: this is Monday evening in the USA)
- Odd weeks of the year: **Wednesday at 9am UTC**
- Use this link to see [the current week of the year](https://whatweekisit.com)
#### How to join
Zoom link will be posted in slack `#-announcements` channel before the call
#### Recording
Recordings of previous calls can be found [here](https://www.youtube.com/playlist?list=PLvm6NqxNNnBLFxZux5OHraTAcIBJz2FvR)
<br>
### What to Work On?
Issues with the label [`status/ready-to-work-on`](https://github.com/blitz-js/blitz/labels/status%2Fready-to-work-on) are the best place to start. If you find one that looks interesting and no one else is already working on it, comment in the issue that you are going to work on it. Please ask as many questions as you need, either directly in the issue or in Slack. We're happy to help!
The Blitzjs.com website and documentation repo also has issues with [`ready to work on | help wanted`](https://github.com/blitz-js/blitzjs.com/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22ready+to+work+on+%7C+help+wanted%22).
#### Things that are ALWAYS welcome
- Adding tests
- Improved documentation
- Improved error messages
- Improved logging (i.e. more clear, more beautiful)
- Performance or security improvements
- Educational content like blogs, videos, courses
If there's some other way you'd like to contribute, just ask us about it in slack!
After you contribute in any way, please add yourself as a contributor via the [@all-contributors bot](https://allcontributors.org/docs/en/bot/usage)!
<br>
## Development Setup
**1.** Fork this repo
**2.** Clone your fork repo
```sh
# If you didn't fork the repo use blitz-js as the USERNAME
git clone git@github.com:USERNAME/blitz.git
cd blitz
```
**3.** Install dependencies
- change version of eslint-parser
- run `yarn --check-files`
- run `./scripts/check-pre-compiled.sh` from `./nextjs/`
- run `yarn build:nextjs` from root
- Try linting again
```
yarn
~/c/blitz> yarn lint
yarn run v1.22.10
$ eslint --ext ".js,.ts,.tsx" .
Oops! Something went wrong! :(
ESLint: 7.21.0
Error: Failed to load parser './parser.js' declared in 'examples/auth/.eslintrc.js » eslint-config-blitz » eslint-config-next': Cannot find module '@babel/parser'
at webpackEmptyContext (/Users/b/c/blitz/nextjs/packages/next/dist/compiled/babel/bundle.js:1:33258)
at Object.73139 (/Users/b/c/blitz/nextjs/packages/next/dist/compiled/babel/bundle.js:2194:783181)
at __nccwpck_require__ (/Users/b/c/blitz/nextjs/packages/next/dist/compiled/babel/bundle.js:2194:1065271)
at Object.eslintParser (/Users/b/c/blitz/nextjs/packages/next/dist/compiled/babel/bundle.js:1:43676)
at Object.<anonymous> (/Users/b/c/blitz/nextjs/packages/next/dist/compiled/babel/eslint-parser.js:1:100)
at Module._compile (/Users/b/c/blitz/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
error Command failed with exit code 2.
```
**4.** Start the package server. This must be running for any package development or example development
##### Failed to compile - LICENSE
This error occurs sometimes when you import code from packages/next/build/utils.ts into some other code like config-shared.ts. Solution is to move the code into another file.
```
yarn dev
```
**5.** Run tests
```
yarn test
```
#### Sync your fork
```sh
./scripts/fetchRemote.sh
git merge upstream/canary
```
#### Link the Blitz CLI (Optional)
The following will link the development CLI as a local binary so you can use it anywhere for testing.
```
yarn link-cli
// `yarn unlink-cli` will unlink
```
#### Develop a Blitz `package`
**1.** Change to a package directory
```
cd packages/core
```
**2.** Start the test runner
```
yarn test:watch
```
#### Develop a Blitz `example`
**1.** Change to an example directory
```
cd examples/store
```
**2.** Follow instructions in the example's README
## Troubleshooting
If you run into issues that should be documented here, please submit a PR! ❤️
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See webpack.js.org/concepts#loaders
> Copyright JS Foundation and other contributors
|
| Permission is hereby granted, free of charge, to any person obtaining
[](https://www.apiseven.com/en/contributor-graph?chart=contributorOverTime&repo=blitz-js/blitz)
Currently at this very early stage it's basically a [BDFL situation](https://opensource.guide/leadership-and-governance/#what-are-some-of-the-common-governance-structures-for-open-source-projects), with me having the final say in decisions.
However we will move away from BDFL to something that looks more like Ember.js. It's extremely important to me (Brandon) that Blitz.js is a long-term, sustainable, and community-run project.
I would love some mentorship from people with experience in large open-source projects on making this transition.
Also, it's possible I will create one or more business around Blitz, perhaps similar to how Taylor Otwell has around Laravel, but Blitz itself will always remain a separate community-run project.
Aside from the core team, there are two levels of maintainers, described below.
## Becoming a Maintainer
We always need more level 1 maintainers! The main requirement is that you can show empathy when communicating online. We'll train you as needed on the other specifics. **This is a great role if you have limited time, because you can spend just as much time as you have without any ongoing responsibilities (unlike level 2)**
Level 2 maintainers have a much higher responsibility, so usually you will spend time as a level 1 maintainer before moving to level 2.
Please DM a core team member (Brandon Bayer, Rudi Yardley, or Dylan Brookes) in Slack if you're interested in becoming an official maintainer!
## Level 1 Maintainers
Level 1 maintainers are critical for a healthy Blitz community and project. They take a lot of burden off the core team and level 2 maintainers so they can focus on higher level things with longer term impact.
The primary responsibilities of level 1 maintainers are:
- Being a friendly, welcoming voice for the Blitz community
- Issue triage
- Pull request triage
- Monitor and answer the `#-help` slack channel
- Community encouragement
- Community moderation
- Tracking and ensuring progress of key issues
## Level 2 Maintainers
Level 2 maintainers are the backbone of the project. They are watchdogs over the code, ensuring code quality, correctness, and security. They also facilitate a rapid pace of progress.
The primary responsibilities of level 2 maintainers are:
- Code ownership over specific parts of the project
- Maintaining and improving the architecture of what they own
- Final pull request reviews
- Merging pull requests
- Tracking and ensuring progress of open pull requests
## ⚠️ Fundamentals
Maintainers are the face of the project and the front-line touch point for the community. Therefore maintainers have the very important responsibility of making people feel welcome, valued, understood, and appreciated.
**Please take time to read and understand everything outlined in this [guide on building welcoming communities](https://opensource.guide/building-community)**
Some especially important points:
- **Gratitude:** immediately express gratitude when someone opens an issue or PR. This takes effort/time and we appreciate it
- **Responsiveness:** during issue/PR triage, even if we can’t do a full review right away, leave a comment thanking them and saying we’ll review it soon
- **Understanding:** it's critical to ensure you understand exactly what someone is saying before you respond. Ask plenty of questions if needed. It's very bad if someone has to reply to your response and say "actually I was asking about X"
- In fact, at least one question is almost always required before you can respond appropriately — whether in Github or in Slack
## Slack
- All `#-*` channels are for Blitz users
- All `#dev-*` channels are for Blitz internal development
If someone that's not a maintainer post in the wrong area, that's fine. Don't tell them they posted in the wrong place. But as a maintainer, you should for sure post in the right channel :)
## Issue Triage
#### If a bug report:
- Does it have enough information? Versions? Logs? Some way to reproduce?
- Has this already been fixed in a previous release?
- Is there already an existing issue for this?
### If a feature/change request:
- Is it clear what the request is and what the benefit will be?
- Is this an obvious win for Blitz? Then accept it
- If not obvious, then pull in a core team member or level 2 maintainer for more review
### Actions
1. Add tags:
- Add a `kind/*` tag
- Add a `scope/*` tag
- Add a `status/*` tag
- Add a good first/second issue tag if appropriate
## Pull Request Triage
- Are the changes covered by tests?
- Do the changes look ok? Make sure there's no obvious issues
### Actions
1. Kindly request any changes if needed
2. Else add a Github approval so that level 2 maintainers know it's already had an initial review
## Final PR Review & Merging (Level 2 maintainers)
As a level 2 maintainer, it is your responsibility to make sure broken code and regressions never reach the canary branch.
1. Ensure the PR'ed code fully works as intended and that there are no regressions in related code
1. If not fully covered by automated tests, you need to pull down the code locally and manually verify everything (the Github CLI helps with this!)
2. During squash & merge:
1. Change the commit title to be public friendly - this exact text will go in the release notes
2. Add the commit type in the description, in parenthesis like `(patch)`. Commit types:
Technology follows a repeating cycle of bundling and unbundling. Created in 2005, Ruby on Rails became a major bundling force. It made web application development easier and more accessible than ever before. This benefited everyone, from those learning programming to seniors building production systems.
A major unbundling happened in 2013 with the release of React because it is hyper focused on the rendering layer. As React grew in popularity, so did the choices for all the other parts, leaving developers with hundreds of decisions to make when starting a new app. While this has contributed to JavaScript Fatigue, it's been a powerful driving force for rapid frontend innovation.
Now, in 2020, is the perfect time for another major bundling. Developers are yearning for an easier, simpler way to build web applications. Beginners want a guiding hand for building a robust app. And seniors want a framework that removes mundane tasks and provides a highly scalable architecture.
Hence the creation of Blitz.
## What is Blitz For?
Blitz is for building tiny to large fullstack database-backed applications that have one or more graphical user interfaces like web or mobile apps.
## Foundational Principles
1. Fullstack & Monolithic
2. API Not Required
3. Convention over Configuration
4. Loose Opinions
5. Easy to Start, Easy to Scale
6. Stability
7. Community over Code
### 1. Fullstack & Monolithic
A fullstack, monolithic application is simpler than an application where frontend and backend are developed and deployed separately. Monolithic doesn't mean it will be slow or hard to scale to large teams. Monolithic doesn't mean there isn't separation of concerns. Monolithic means you can reason about your app as a single entity.
### 2. API Not Required
Until now, choosing React for your view layer required you to have a REST or GraphQL API even if it wasn't used by third-parties. This additional complexity is a significant drawback not shared by traditional server rendered apps like Ruby on Rails.
Blitz is a framework for the 99% of us at companies with <100 employees. The vast majority of these apps don't actually need an API, at least not until years down the road when you have the time and resources to build one.
### 3. Convention over Configuration
Starting a new fullstack React app is currently too hard. You have to spend days on things like configuring eslint, prettier, husky, jest, cypress, typescript, deciding on a file structure, setting up a database, adding authentication and authorization, setting up a router, defining routing conventions, and setting up your styling library.
Blitz makes as many decisions and does as much work for you as possible. This makes it lightning fast to start real development. It also greatly benefits the community. Common project structure and architectural patterns make it easy to move from Blitz app to Blitz app and immediately feel at home.
Convention over configuration doesn't mean no configuration. It means configuration is optional. Blitz will provide all the escape hatches you need for bespoke customization.
### 4. Loose Opinions
Blitz is opinionated. The out-of-the-box experience guides you on a path perfect for most applications. However, Blitz isn't arrogant. It understands there are very good reasons for deviating from convention, and it allows you to do so. For example, Blitz has a conventional file structure, but, with few exceptions, doesn't _enforce_ it.
And when there's not community consensus, `blitz new` prompts you to choose.
### 5. Easy to Start, Easy to Scale
A framework that's only easy for one end of an application lifecycle is not a good framework. Both starting and scaling must be easy.
Easy to start includes being easy for beginners and being easy to migrate existing Next.js apps to Blitz.
Scaling is important in all forms: lines of code, number of people working in the codebase, and code execution.
### 6. Stability
In the fast-paced world of Javascript, a stable, predictable release cycle is a breath of fresh air. A stable release cycle ensures minimal breaking changes, and it ensures you know exactly what and when a breaking change will occur. It also minimizes bugs in stable releases by ensuring features are in beta for a minimum amount of time. [Ember is the model citizen](https://emberjs.com/releases/) in this regard.
The exact details of the Blitz release cycle are to be determined, but we'll follow a pattern similar to Ember which strictly follows SemVer with stable releases every 6 weeks and LTS releases every 6 months.
Blitz will follow a public RFC (request for comments) process so all users and companies can participate in proposing and evaluating new features.
If a Blitz API needs to be removed, it will be deprecated in a minor release. Major releases will simply remove APIs already deprecated in a previous release.
### 7. Community over Code
The Blitz community is the most important aspect of the framework, by far.
We have a comprehensive [Code of Conduct](https://github.com/blitz-js/blitz/blob/canary/CODE_OF_CONDUCT.md). LGBTQ+, women, and minorities are especially welcome.
We are all in this together, from the youngest to the oldest. We are all more similar than we are different. We can and should solve problems together. We should learn from other communities, not compete against them.
- Next major release will include auth by default and allow you to choose your form library
- Next auth features are email confirmation
- After that, logging and plugins are next
- Adam:
- Overhauled the recipe infrastructure. Now using jscodeshift instead of recast
- Added support for conditional JSX in templates
- Going to work on custom templates next
- Dwight
- Has been opening issues for problems
- Made a few PRs for some issues
# 2020-07-07 Blitz Contributor Call
- Attending: Brandon Bayer, Robert Rosenburg, Jeremy Liberman
- Brandon:
- Finishing up session managment code
- Waiting for review of session managment code from Rishabh
- Will be working on actual auth code (vs session management) like password hashing, password reset, social login, etc.
- Benefits of our session managment vs rails
- Don’t have to redirect to login page
- Using top level error component that catches authentication errors
- You can login from anywhere, during sign up
- Robert:
- Waiting on Kirstina’s website designs. Desktop design is finished, but she's working on mobile design
- Code snippet / sandbox of blitz code for the website
# 2020-06-23 Blitz Contributor Call
- Attending: Brandon Bayer, Robert Rosenberg, Justin Hall, Adam Markon
- Brandon:
- Server side session management code is mostly set up. Still need to integrate client side of RPC calls to expose session information
- Identity verification/Oauth integrations still need to be firmed up
- Once auth is wrapped up we should be ready to start on plugins
- Adam:
- Been experimenting with smart page generation based on the current schema model
- MDX installer recipes
- Robert:
- Waiting on designs from Kristina
- Prism component from theme ui customization? If not try and grab source code from docusaurus line highlighting component
- Justin:
- Updated the tutorial
- Helped with various bug fixes
# 2020-06-17 Blitz Contributor Call
- Attending: Brandon Bayer, Fran Zekan, Sigurd Wahl
- Brandon:
- Spent the past week implementing HTTP middlware which is now released!
- Now working on implementing session management!
- Fran:
- Finishing up the PR for adding `blitz db seed`
- Sigurd:
- New to the community, slowly learning the codebase
- Exicited to get a first PR in here sometime soon :)
# 2020-06-09 Blitz Contributor Call
- Attending: Brandon Bayer, Rudi Yardley, Fran Zekan, Adam Markon, Robert Rosenberg, Kristina Matuska
- Brandon:
- blitzjs.com published, docs + marketing site v0.1 live
- For now most of the docs copied from react-query and Next, we should eventually clean them up so they're stylistically similar to ours, but really easy to start
- HTTP middleware is almost done, just fixing a few edge cases
- Authentication is up next after that, translating pseudocode into actual code
- Kristina:
- Homepage design mostly wrapped up right now, have to finish up mobile and light mode and then ready to move on to the rest of the docs
- Syntax highlighting, we can customize colors
- Sidebar inspiration from tailwindcss
- Robert:
- Decided to wait to convert existing components to theme UI until the final design is done
- More docs content:
- More guides
- Improve the tutorial to incorporate relationship generation
- Add branches for canary and master
- If you add a feature you can add your documentation to the canary branch
- Adam:
- blitz generate model finished!
- Installer rewrite complete
- At similar place to what Gatsby has for installing stuff
- Next up:
- Support gatsby MDX recipes
- Make all code generators aware of actual model attributes
- Fran:
- Working on a package for getting the blitz config anywhere - getConfig()
- Prevent app from "warming" the server when deployed as server rather than serverless
- Testing examples - e2e with cypress and unit tests with Jest so we can link to a testing setup in the docs/getting started guide
- Rudi:
- Extracted out the @blitzjs/file-pipeline (previously synchronizer)
- Extracted out the @blitzjs/display package
- Working on various Next.js compatibility issues
- Debugging a bug in blitz start where it gets stuck at \_manifest.json
# 2020-05-26 Blitz Contributor Call
- Attending: Brandon Bayer, Robert Rosenberg, Adam Markon, Simon Debbarma
- Brandon:
- Kitze livestream last week went great — recording on youtube
- Codebase walkthrough yesterday went great — recording on youtube
- Website overhaul, installed Theme UI
- Adam:
- Opened PR for Prisma model generation from the CLI
- Working on Installer stuff and prepping for integration with Gatsby recipes
- Simon
- Working on custom illustrations for the web
- Robert
- Misc work on website
- Website
- Most website components are owned by us now instead of docusaurus, we'll need to be weary of api updates and any other important component updates
- Make sidebar like tailwind docs sidebar
- Dark theme needs to be fixed
- Theme switcher inconsistent
- Live code sandbox examples
- Code comparison between blitz and rails
- Auth
- Rishabh continuing to work on pseudo code for the session management library
- Brandon planning to build http middleware support this week
- CLI
- Adam working on new features, including generating prisma models and making existing templates aware of actual model attributes
- Plugin ideas / discussion once recipes are farther along. Will post an RFC for plugins at some point
<h5 align="center">"Zero-API" Data Layer — Built on Next.js — Inspired by Ruby on Rails</h3>
<h3 align="center"><a href="https://blitzjs.com/docs/get-started" target="_blank">Read the Documentation</a></h3>
<br>
“Zero-API” data layer **lets you import server code directly into your React components** instead of having to manually add API endpoints and do client-side fetching and caching.
New Blitz apps come with **all the boring stuff already set up for you!** Like ESLint, Prettier, Jest, user sign up, log in, and password reset.
Provides **helpful defaults and conventions** for things like routing, file structure, and authentication while also being extremely flexible.
<br>
Blitz brings back the **simplicity and conventions** of server-rendered frameworks like Ruby on Rails while preserving everything we love about React and client-side rendering!
### Quick Start
Blitz is the framework for the 99% of us at companies with <100 employees. This means **we don't force you to use advanced technologies like GraphQL**. We let you add advanced technologies on your terms and at your pace.
You need Node.js 12 or newer
Blitz **maximizes your productivity** both when starting an app and when scaling it to lots of code and users.
#### Install Blitz
<br>
Run `npm install -g blitz` or `yarn global add blitz`
### :tada: Alpha Release Now Available :tada:
_You can alternatively use [`npx`](https://www.npmjs.com/package/npx)_
1.`npm i -g blitz`
2.`blitz new myapp`
3. [Read the Alpha User Guide](https://github.com/blitz-js/blitz/blob/canary/USER_GUIDE.md)
#### Create a New App
or
1.`blitz new myAppName`
2.`cd myAppName`
3.`blitz dev`
4. View your brand new app at http://localhost:3000
3. Start with the [Blitz Beginner Tutorial](https://github.com/blitz-js/blitz/blob/canary/TUTORIAL.md)
⚡️ Don't have to build an API for client-side rendering<br>
⚡️ Client-side rendering, Server-side rendering, and fully static pages all in the same app<br>
⚡️ Full Typescript support with static, end-to-end typing (no code generation step needed like with GraphQL)<br>
⚡️ React Concurrent Mode enabled<br>
⚡️ Database/ORM agnostic, but Prisma 2 is default<br>
⚡️ CLI with code scaffolding, Rails-style console REPL, etc<br>
⚡️ GraphQL Ready<br>
⚡️ Deploy serverless or serverful<br>
**Other key features coming:**<br>
⚡️ Highly secure authentication <br>
⚡️ Authorization you can use on both server and client<br>
⚡️ Model validation you can use on both server and client<br>
⚡️ Plugins for easily adding libraries like Tailwind, CSS-in-JS, etc.<br>
⚡️ React native support<br>
⚡️ GUI so you don't have to use the CLI<br>
<br><br>
### The Foundational Principles
1. Fullstack & Monolithic
2. API Not Required
3. Convention over Configuration
4. Loose Opinions
5. Easy to Start, Easy to Scale
6. Stability
7. Community over Code
[The Blitz Manifesto](https://blitzjs.com/docs/manifesto) explains these principles in detail.
<br>
@@ -72,38 +84,89 @@ While we currently only support web, we are pursuing the dream of a single monol
<br>
### What are the Foundational Principles?
1. Fullstack & Monolithic
2. API Not Required
3. Convention over Configuration
4. Loose Opinions
5. Easy to Start, Easy to Scale
6. Stability
7. Community over Code
[The Blitz Manifesto](https://github.com/blitz-js/blitz/blob/canary/MANIFESTO.md) explains these principles in detail.
<br>
## Welcome to the Blitz Community 👋
The Blitz community is warm, safe, diverse, inclusive, and fun! LGBTQ+, women, and minorities are especially welcome. Please read our [Code of Conduct](https://github.com/blitz-js/blitz/blob/canary/CODE_OF_CONDUCT.md).
The Blitz community is warm, safe, diverse, inclusive, and fun! LGBTQ+, women, and minorities are especially welcome. Please read our [Code of Conduct](https://blitzjs.com/docs/code-of-conduct).
[Join our Slack Community](https://slack.blitzjs.com) where we help each other build Blitz apps. It's also where we collaborate on building Blitz itself.
[Join our Discord Community](https://discord.blitzjs.com) where we help each other build Blitz apps. It's also where we collaborate on building Blitz itself.
There's still a lot of work to do, so you are especially invited to join us in building Blitz! A good place to start is [The Contributing Guide](CONTRIBUTING.md).
For questions and longer form discussions, [post in our forum](https://github.com/blitz-js/blitz/discussions).
There's still a lot of work to do, so you are especially invited to join us in building Blitz! A good place to start is [The Contributing Guide](https://blitzjs.com/docs/contributing).
<br>
## Sponsors and Donations
## Financial Contributors
- Contribute via [GitHub Sponsors](https://github.com/sponsors/blitz-js)
- Contribute via [PayPal](https://paypal.me/thebayers)
- Contribute via [Open Collective](https://opencollective.com/blitzjs)
- Contribute via [Patreon](https://patreon.com/flybayer)
Your financial contributions help ensure Blitz continues to be developed and maintained! We have monthly sponsorship options starting at $5/month.
_Sponsor Blitz and display your logo and hiring status here. This is a great way to get in front of early adopters!_
👉 View options and contribute at [GitHub Sponsors](https://github.com/sponsors/blitz-js), [PayPal](https://paypal.me/thebayers), or [Open Collective](https://opencollective.com/blitzjs)
@@ -142,22 +205,54 @@ _Code ownership, pull request approvals and merging, etc_ (see [MAINTAINERS.md](
## Maintainers (Level 1) ✨
_Issue triage, pull request triage, community encouragement and moderation, etc_ (see [MAINTAINERS.md](./MAINTAINERS.md))
We need more woman & nonbinary level 1 maintainers. See [MAINTAINERS.md](./MAINTAINERS.md) for what this entails
_Issue triage, pull request triage, community encouragement and moderation, etc_ (see [Maintainers L1](https://blitzjs.com/docs/maintainers#level-1-maintainers))
← [Back to Alpha Guide](https://github.com/blitz-js/blitz/blob/canary/USER_GUIDE.md)
Thanks for trying out Blitz! In this tutorial, we’ll walk you through the creation of a basic voting application.
We’ll assume that you have [Blitz installed](https://github.com/blitz-js/blitz/blob/canary/USER_GUIDE.md#blitz-app-development) already. You can tell if Blitz is installed, and which version you have by running the following command in your terminal:
```sh
$ blitz -v
```
If Blitz is installed, you should see the version of your installation. If it isn’t, you’ll get an error saying something like “command not found: blitz”.
## Creating a project
If this is your first time using Blitz, you’ll have to begin with some initial setup. We provide a command which takes care of all this for you, generating the configuration and code you need to get started.
From the command line, `cd` into the directory where you’d like to store your code, and then run the following command to create a new TypeScript blitz project:
```sh
blitz new mysite
```
*Note, you can create a JavaScript blitz project instead by running `blitz new mysite --js`; however, this tutorial assumes a TypeScript project.*
This should create a `mysite` directory in your current directory.
Let’s look at what `blitz new` created:
```
mysite
├── app
│ ├── components
│ │ └── ErrorBoundary.tsx
│ ├── layouts
│ └── pages
│ ├── _app.tsx
│ ├── _document.tsx
│ └── index.tsx
├── db
│ ├── migrations
│ ├── index.ts
│ └── schema.prisma
├── integrations
├── jobs
├── node_modules
├── public
│ ├── favicon.ico
│ └── logo.png
├── utils
├── .babelrc.js
├── .env
├── .eslintrc.js
├── .gitignore
├── .npmrc
├── .prettierignore
├── README.md
├── blitz.config.js
├── package.json
├── tsconfig.json
└── yarn.lock
```
These files are:
- The `app/` directory is a container for most of your project. This is where you’ll put any pages or API routes.
-`db`/ is where your database configuration goes. If you’re writing models or checking migrations, this is where to go.
-`node_modules/` is where your “dependencies” are stored. This directory is updated by your package manager, so you don’t have to worry too much about it.
-`public/` is a directory where you will put any static assets. If you have images, files, or videos which you want to use in your app, this is where to put them.
-`utils/` is a good place to put any shared utility files which you might use across different sections of your app.
-`.babelrc.js`, `.env`, etc. ("dotfiles") are configuration files for various bits of JavaScript tooling.
-`blitz.config.js` is for advanced custom configuration of Blitz. It extends [`next.config.js`](https://nextjs.org/docs/api-reference/next.config.js/introduction).
-`package.json` contains information about your dependencies and devDependencies. If you’re using a tool like `npm` or `yarn`, you won’t have to worry about this much.
-`tsconfig.json` is our recommended setup for TypeScript.
## The development server
Let’s check that your Blitz project works. Make sure you are in the `mysite` directory, if you haven’t already, and run the following command:
```sh
$ blitz start
```
You’ll see the following output on the command line:
```sh
✔ Prepped for launch
[wait] starting the development server ...
[ info ] waiting on http://localhost:3000 ...
[ info ] bundled successfully, waiting for typecheck results...
[wait] compiling ...
[ info ] bundled successfully, waiting for typecheck results...
[ ready ] compiled successfully - ready on http://localhost:3000
```
Now that the server’s running, visit http://localhost:3000/ with your Web browser. You’ll see a welcome page, with the Blitz logo. It worked!
## Write your first page
Now that your development environment—a “project”—is set up, you’re ready to start building out the app. First, we’ll create your first page.
Open the file `app/pages/index.tsx` and put the following code in it:
```tsx
exportdefault()=>(
<div>
<h1>Hello,world!</h1>
</div>
)
```
This is the simplest page possible in Blitz. To look at it, go back to your browser and go to http://localhost:3000. You should see your text appear! Try editing the `index.tsx` file, and make it your own! When you’re ready, move on to the next section.
## Database setup
Now, we’ll setup the database and create your first model.
Open up `db/schema.prisma`. It’s a configuration file which our default database engine Prisma uses.
By default, the apps is created with SQLite. If you’re new to databases, or you’re just interested in trying Blitz, this is the easiest choice. Note that when starting your first project, you may want to use a more scalable database like PostgreSQL, to avoid the pains of switching your database down the road.
## Creating models
Now we’ll define your models — essentially your database layout — with additional metadata.
In `schema.prisma`, we’ll create two models: `Question`, and `Choice`. A `Question` has a question and a publication date. A `Choice` has two fields: the text of the choice and a vote count. Each has an id, and each `Choice` is associated with a `Question`.
Edit the `schema.prisma` file so it looks like this:
Now, we need to migrate our database. This is a way of telling it that you have edited your schema in some way. Run the below command. When it asks you to enter a migration name you can enter anything you want, perhaps `
"init db":
```sh
$ blitz db migrate
```
## Playing with the API
Now, let’s hop into the interactive Blitz shell and play around with the free API Blitz gives you. To invoke the Blitz console, use this command:
```sh
$ blitz console
```
Once you’re in the console, explore the Database API:
[//]: # 'Let’s move this to await when it’s available for all */'
Let’s create some more pages. Blitz provides a handy utility for scaffolding out pages, called `generate`. Let’s run it now with our `Question` model:
```sh
$ blitz generate all question
```
Great! Before running the app again, we need to customise some of these pages which have just been generated. Open your text editor and look at `app/questions/pages/index.tsx`. Notice that a `QuestionsList` component has been generated for you:
This won’t work though! Remember that the `Question` model we created above doesn’t have any `name` field. To fix this, replace `question.name` with `question.text`:
data: {text: 'Do you love Blitz?', publishedAt: new Date()},
})
```
Finally, we just need to fix the edit page. Open `app/questions/pages/questions/[id]/edit.tsx` and replace
```jsx
const updated = await updateQuestion({
where: {id: question.id},
data: {name: 'MyNewName'},
})
```
with
```jsx
const updated = await updateQuestion({
where: {id: question.id},
data: {text: 'Do you really love Blitz?'},
})
```
Great! Now make sure your app is running. If it isn’t, just run `blitz start` in your terminal, and visit http://localhost:3000/questions. Play around with your new app a bit! Try creating questions, editing, and deleting them.
## Writing a minimal form
You’re doing great so far! The next thing we’ll do is give our form some real inputs. At the moment it’s giving every `Question` the same name! Have a look at `app/questions/pages/questions/new.tsx` in your editor.
Delete the div that says: `<div>Put your form fields here. But for now, just click submit</div>`, and replace it with some inputs:
```jsx
<input placeholder="Name" />
<input placeholder="Choice 1" />
<input placeholder="Choice 1" />
<input placeholder="Choice 1" />
```
Finally, we’re going to make sure all that data is submitted. In the end, your page should look something like this:
```jsx
import {Head, Link, useRouter} from 'blitz'
import createQuestion from 'app/questions/mutations/createQuestion'
Time for a breather. Go back to `http://localhost:3000/questions` in your browser and look at all the questions you‘ve created. How about we list these questions’ choices here too? First, we need to customise the question queries. In Prisma, you need to manually let the client know that you want to query for nested relations. Change your `getQuestion.ts` and `getQuestions.ts` files to look like this:
```js
// app/questions/queries/getQuestion.ts
import db, {FindOneQuestionArgs} from 'db'
export default async function getQuestion(args: FindOneQuestionArgs) {
Now hop back to our main questions page in your editor, and we can list the choices of each question easily. Just add this code beneath the `Link` in our `QuestionsList`:
```jsx
<ul>
{question.choices.map((choice) => (
<li key={choice.id}>
{choice.text} - {choice.votes} votes
</li>
))}
</ul>
```
Magic! Let’s do one more thing–let people vote on these questions!
Open `app/questions/pages/questions/[id].tsx` in your editor. First, we’re going to improve this page somewhat.
1. Replace `<h1>Question {question.id}</h1>` with `<h1>{question.text}</h1>`.
2. Delete the `pre` element, and copy in our choices list which we wrote before:
```jsx
<ul>
{question.choices.map((choice) => (
<li key={choice.id}>
{choice.text} - {choice.votes} votes
</li>
))}
</ul>
```
If you go back to your browser, your page should now look something like this!
<img width="567" alt="Screenshot 2020-04-27 at 16 06 55" src="https://user-images.githubusercontent.com/24858006/80387990-3c3d8b80-88a1-11ea-956a-5be85f1e8f12.png">
Now that you’ve improved the question page, it’s time for the vote button.
First, we need a new mutation. Create a file at `app/questions/mutations/updateChoice.ts`, and paste in the following code:
```js
import db, {ChoiceUpdateArgs} from 'db'
export default async function updateChoice(args: ChoiceUpdateArgs) {
// Don't allow updating ID
delete args.data.id
const choice = await db.choice.update(args)
return choice
}
```
Back in `app/questions/pages/questions/[id].tsx`, we can now add a vote button.
In our `li`, add a button like so:
```jsx
<li key={choice.id}>
{choice.text} - {choice.votes} votes
<button>Vote</button>
</li>
```
Then, import our `updateChoice` mutation, and create a `handleVote` function in our page:
```jsx
import updateChoice from "app/questions/mutations/updateChoice"
🥳 Congrats! You just created your very own Blitz app! Have fun playing around with it, or sharing it with your friends. Now that you’ve finished this tutorial, why not try making your voting app even better? You could try:
- Adding styling
- Showing some more statistics about votes
- Deploying live so you can send it around (we recommend [Vercel](https://vercel.com/))
If you want to share your project with the world wide Blitz community there is no better place to do that than on Slack.
Just visit https://slack.blitzjs.com. Then, post the link to the **#show-and-tell** channel to share it with everyone!

<br>
Before getting started, you should know **this is alpha software**. Blitz is incomplete. There are rough spots and bugs. APIs may change. But you can build an app and deploy it to production. We're excited to see what you build!
If you have any issues at all, please [open an issue](https://github.com/blitz-js/blitz/issues/new/choose) or join the [Blitz slack](https://slack.blitzjs.com) and talk to us in the **#help** channel. If you get stuck and frustrated, please don't blame yourself. This user guide, and Blitz in general, is not yet fine-tuned for those with less experience. But eventually, it will be because this is very important to us.
If you’re looking for a slower, more guided start to Blitz, read the **[Blitz Beginner Tutorial](https://github.com/blitz-js/blitz/blob/canary/TUTORIAL.md)**.
<br>
## Introduction
Blitz is a Rails-like framework for building monolithic, full-stack React apps. The idea is that Blitz makes you extremely productive by doing as much set up and grunt work for you.
**When building a Blitz app, you don’t have to think about “building an API” or “fetching data from your API”**. You only think about writing functions that get and change data. And to use those functions in your component, you simply import and call them like a regular function.
Blitz is built on Next.js, so if you are familiar with that, you will feel right at home.
<br>
## Blitz App Development
### Set Up Your Computer
- [ ] You need Node.js 12 or newer
<br>
### Create Your Blitz App
1.`npm install -g blitz` or `yarn global add blitz`
2. Run `blitz new myAppName` to create a new TypeScript blitz app in the `myAppName` directory. Alternatively, run `blitz new myAppName --js` to create a JavaScript blitz app
3.`cd myAppName`
4.`blitz start`
5. View your baby app at [http://localhost:3000](http://localhost:3000)
<br>
### Set Up Your Database
By default, Blitz uses Prisma 2 which is a strongly typed database client. **You probably want to read [the Prisma 2 documentation](https://www.prisma.io/docs/understand-prisma/introduction).**_Note, Prisma 2 is not required for Blitz. The only Prisma-Blitz integration is the `blitz db` cli command. You can use anything you want, such as Mongo, TypeORM, etc._
- If this fails, you need to change the `DATABASE_URL` value in `.env` to whatever is required by your Postgres installation.
<br>
### Scaffold out all the files your basic CRUD actions
_CRUD = create, read, update, delete_
1. Run `blitz generate all project` to generate fully working queries, mutations, and pages
2. Open [http://localhost:3000/projects](http://localhost:3000/projects) to see the default project list page
3. Explore the generated pages and view, create, update, and delete projects.
<br>
### Pages
Blitz.js pages are exactly the same as Next.js pages. If you need, read [the Next.js Page documentation](https://nextjs.org/docs/basic-features/pages)
- Unlike Next.js, you can have many `pages/` folders nested inside `app/`. This way pages can be organized neatly, especially for larger projects. Like this:
- All React components inside a `pages/` folder are accessible at a URL corresponding to its path inside `pages/`. So `pages/about.tsx` will be at `localhost:3000/about`.
The Next.js router APIs are all exported from the `blitz` package: `useRouter()`, `withRouter()`, and `Router`. If you need, read [the Next.js Router documentation](https://nextjs.org/docs/api-reference/next/router).
<br>
### Writing Queries & Mutations
Blitz queries and mutations are plain, asynchronous Javascript functions that always run on the server.
We automatically alias the root of your project, so `import db from 'db'` is importing `<project_root>/db/index.ts`
// Can do any pre-processing or event triggers here
constproduct=awaitdb.product.create(args)
// Can do any post-processing or event triggers here
returnproduct
}
```
<br>
### Using Queries
#### In a React Component
Blitz provides a `useQuery` hook, which is built on [`react-query`](https://github.com/tannerlinsley/react-query). The first argument is a query function. The second argument is the input to the query function. The third argument is any valid react-query configuration item.
At build time, the direct function import is swapped out for a function that executes a network call to run the query serverside.
**React Concurrent Mode is enabled by default for Blitz apps.** So the `<Suspense>` component is used for loading states and `<ErrorBoundary>` is used to display errors. If you need, you can read the [React Concurrent Mode Docs](https://reactjs.org/docs/concurrent-mode-intro.html).
For more details, read the comprehensive [Query & Mutation Usage Issue](https://github.com/blitz-js/blitz/issues/89)
<br>
### Custom API Routes
Blitz.js custom API routes are exactly the same as Next.js custom API routes. If you need, read [the Next.js API route documentation](https://nextjs.org/docs/api-routes/introduction)
- Unlike Next.js, your `api/` folder must be a sibling of `pages/` instead of being nested inside.
- All React components inside an `api/` folder are accessible at a URL corresponding to it's path inside `api/`. So `app/projects/api/webhook.tsx` will be at `localhost:3000/api/webhook`.
<br>
### Customize the Webpack Config
Blitz uses the `blitz.config.js` config file at the root of your project. This is exactly the same as `next.config.js`. Read [the Next.js docs on customizing webpack](https://nextjs.org/docs/api-reference/next.config.js/custom-webpack-config).
<br>
### Deploy to Production
1. You need a production Postgres database. It's easy to set this up on [Digital Ocean](https://www.digitalocean.com/products/managed-databases-postgresql/?refcode=466ad3d3063d).
2. For deploying serverless, you also need a connection pool. This is also relatively easy to set up on Digital Ocean.
1. [Read the Digital Ocean docs on setting up your connection pool](https://www.digitalocean.com/docs/databases/postgresql/how-to/manage-connection-pools/#creating-a-connection-pool?refcode=466ad3d3063d)
2. Ensure you set your "Pool Mode" to be "Session" instead of "Transaction" (because of a bug in Prisma)
3. You need your entire database connection string. If you need, [read the Prisma docs on this](https://www.prisma.io/docs/reference/database-connectors/postgresql#connection-details).
1. If deploying to serverless with a connection pool, make sure you get the connection string to your connection pool, not directly to the DB.
4. You need to change the defined datasource in `db/schema.prisma` from SQLite to Postgres
#### Serverless
Assuming you already have a Vercel account and the `now` cli installed, you can do the following:
1. Add your DB url as a secret environment variable by running `now secrets add @database-url "DATABASE_CONNECTION_STRING"`
2. Add a `now.json` at your project root with
```json
{
"env":{
"DATABASE_URL":"@database-url"
},
"build":{
"env":{
"DATABASE_URL":"@database-url"
}
}
}
```
3. Run `now`
Once working and deployed to production, your app should be very stable because it’s running Next.js which is already battle-tested.
#### Traditional, Long-Running Server
You can deploy a Blitz app like a regular Node or Express project.
`blitz start --production` will start your app in production mode. Make sure you provide the `DATABASE_URL` environment variable for your production database.
<br>
## Blitz CLI Commands
#### `blitz new NAME`
Generate a new TypeScript blitz project at `<current_folder>./NAME`
#### `blitz new NAME --js`
Generate a new JavaScript blitz project at `<current_folder>./NAME`
#### `blitz start`
Start your app in development mode
#### `blitz start --production`
Start your app in production mode
#### `blitz db migrate`
Run any needed migrations via Prisma 2 and generate Prisma Client
#### `blitz db introspect`
Will introspect the database defined in `db/schema.prisma` and automatically generate a complete `schema.prisma` file for you. Lastly, it'll generate Prisma Client.
#### `blitz db studio`
Open the Prisma Studio UI at [http://localhost:5555](http://localhost:5555) so you can easily see and change data in your database.
#### `blitz generate -h`
Generate different types of files for a model. Your model input can be singular or plural, but the generated files will be the same in both cases.
#### `blitz console`
Start a Node.js REPL that's preloaded with your `db` object and all your queries and mutations. This is awesome for quickly trying your code without running the app!
<br>
## More Information
- Read the [Architecture RFC](https://github.com/blitz-js/blitz/pull/73) for more details on the architecture, our decision making, and how queries/mutations work under the hood
- Read the [File Structure & Routing RFC](https://github.com/blitz-js/blitz/pull/74) for more details about the file structure and routing conventions.
- View an example Blitz app at [`examples/store`](https://github.com/blitz-js/blitz/tree/canary/examples/store)
<br>
## What's Next for Blitz.js?
Here's the list of big things that are currently missing from Blitz but are a top priority for us:
- A real Blitzjs.com website and documentation
- Translated documentation. If you're interested in helping, [comment in this issue](https://github.com/blitz-js/blitzjs.com/issues/20).
- Authentication
- Authorization (use auth rules both on server and client)
- Model validation (use model validation both on server and client)
- React-Native support
- GUI for folks who prefer that over CLIs
- ... and tons more 🙂
<br>
## FAQ
- **Will you support other ESLint configs for the `blitz new` app?** Yes, there's [an issue for this](https://github.com/blitz-js/blitz/issues/161)
<br>
## You are invited to help — let’s build the future of web dev together! 🤝
Blitz is just getting started, and it's going to take an entire community to bring it to fruition!
How you can help:
1. Tell others about Blitz
2. Report bugs by opening an issue here on GitHub
3. Send us feedback in the [Blitz slack](https://slack.blitzjs.com).
4. Contribute code. We have a lot of issues that are ready to work on! Start by reading [The Contributing Guide](https://github.com/blitz-js/blitz/blob/canary/CONTRIBUTING.md). Let us know if you need help.
5. Any way you want! We totally appreciate any type of contribution, such as documentation, videos, blog posts, etc. If you have a crazy idea, feel free to run it past us in Slack! :)
// This function is called when a project is opened or re-opened (e.g. due to
// the project's config changing)
/**
* @type {Cypress.PluginConfig}
*/
//@ts-ignore
module.exports=(on,config)=>{
// `on` is used to hook into various events Cypress emits
// `config` is the resolved Cypress config
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.