docs: merge latest docs from next

docs/code-of-conduct.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [github@patcavit.com](mailto:github@patcavit.com?subject=Mithril Code of Conduct). All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

docs/components.md

@@ -316,7 +316,7 @@ var Login = {
 
 Normally, in the context of a larger application, a login component like the one above exists alongside components for user registration and password recovery. Imagine that we want to be able to prepopulate the email field when navigating from the login screen to the registration or password recovery screens (or vice versa), so that the user doesn't need to re-type their email if they happened to fill the wrong page (or maybe you want to bump the user to the registration form if a username is not found).
 
-Right away, we see that sharing the `username` and `password` fields from this component to another is difficult. This is because the fat component encapsulates its our state, which by definition makes this state difficult to access from outside.
+Right away, we see that sharing the `username` and `password` fields from this component to another is difficult. This is because the fat component encapsulates its state, which by definition makes this state difficult to access from outside.
 
 It makes more sense to refactor this component and pull the state code out of the component and into the application's data layer. This can be as simple as creating a new module:
 

docs/es6.md

@@ -5,7 +5,7 @@
 
 ---
 
-Mithril is written in ES5, and is fully compatible with ES6 as well. ES6 is a recent update to Javascript that introduces new syntax sugar for various common cases. It's not yet fully supported by all major browsers and it's not a requirement for writing application, but it may be pleasing to use depending on your team's preferences.
+Mithril is written in ES5, and is fully compatible with ES6 as well. ES6 is a recent update to Javascript that introduces new syntax sugar for various common cases. It's not yet fully supported by all major browsers and it's not a requirement for writing an application, but it may be pleasing to use depending on your team's preferences.
 
 In some limited environments, it's possible to use a significant subset of ES6 directly without extra tooling (for example, in internal applications that do not support IE). However, for the vast majority of use cases, a compiler toolchain like [Babel](https://babeljs.io) is required to compile ES6 features down to ES5.
 

docs/jsx.md

@@ -39,7 +39,7 @@ When using JSX, it's possible to interpolate Javascript expressions within JSX t
 var greeting = "Hello"
 var url = "http://google.com"
 var link = <a href={url}>{greeting + "!"}</a>
-// yields <a href="http://google.com">Hello</a>
+// yields <a href="http://google.com">Hello!</a>
 ```
 
 Components can be used by using a convention of uppercasing the first letter of the component name:

docs/mount.md

@@ -27,6 +27,10 @@ var Counter = {
 m.mount(document.body, Counter)
 ```
 
+To pass arguments when mounting a component use:
+```javascript
+m.mount(element, {view: function () {return m(Component, attrs)}})
+```
 ---
 
 ### Signature

docs/nav-guides.md

@@ -19,6 +19,7 @@
 	- [Mithril Jobs](https://github.com/lhorie/mithril.js/wiki/JOBS)
 	- [How to contribute](contributing.md)
 	- [Credits](credits.md)
+	- [Code of Conduct](code-of-conduct.md)
 - Misc
 	- [Framework comparison](framework-comparison.md)
 	- [Change log/Migration](change-log.md)

docs/releasing.md

@@ -4,19 +4,44 @@
 
 ### Prepare the release
 
-1. Determine patch level of the change
-2. Update information in `docs/change-log.md` to match reality & the new version that will be released
+1. Ensure your local branch is up to date
+
+```bash
+$ git co next
+$ git pull --rebase lhorie next
+```
+
+2. Determine patch level of the change
+3. Update information in `docs/change-log.md` to match reality of the new version being prepared for release
+4. Commit changes to `next`
+
+```
+$ git add .
+$ git commit -m "Preparing for release"
+
+# Push to your branch
+$ git push
+
+# Push to lhorie/mithril.js
+$ git push lhorie next
+```
 
 ### Merge from `next` to `master`
 
-3. Switch to `master` and merge `next` on top of it
+5. Switch to `master` and make sure it's up to date
 
 ```bash
 $ git co master
+$ git pull --rebase lhorie master
+```
+
+6. merge `next` on top of it
+
+```bash
 $ git merge next
 ```
 
-4. Clean & update npm dependencies and ensure the tests are passing.
+7. Clean & update npm dependencies and ensure the tests are passing.
 
 ```bash
 $ npm prune
@@ -26,12 +51,43 @@ $ npm test
 
 ### Publish the release
 
-5. `npm run release <major|minor|patch|semver>`, see the docs for [`npm version`](https://docs.npmjs.com/cli/version)
-6. Travis will push the new release to npm & create a GitHub release
+8. `npm run release <major|minor|patch|semver>`, see the docs for [`npm version`](https://docs.npmjs.com/cli/version)
+9. The changes will be automatically pushed to your fork
+10. Push the changes to `lhorie/mithril.js`
+
+```bash
+$ git push lhorie master
+```
+
+11. Travis will push the new release to npm & create a GitHub release
+
+### Merge `master` back into `next`
+
+This helps to ensure that the `version` field of `package.json` doesn't get out of date.
+
+12. Switch to `next` and make sure it's up to date
+
+```bash
+$ git co next
+$ git pull --rebase lhorie next
+```
+
+13. Merge `master` back onto `next`
+
+```bash
+$ git merge master
+```
+
+14. Push the changes to your fork & `lhorie/mithril.js`
+
+```bash
+$ git push
+$ git push lhorie next
+```
 
 ### Update the GitHub release
 
-7. The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the `docs/change-log.md` entry for the build.
+15. The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the `docs/change-log.md` entry for the build.
 
 ## Updating mithril.js.org
 

docs/route.md

@@ -319,6 +319,20 @@ m.route(document.body, "/edit/pictures/image.jpg", {
 })
 ```
 
+#### Handling 404s
+
+For isomorphic / universal javascript app, an url param and a variadic route combined is very usefull to display custom 404 error page.
+
+In a case of 404 Not Found error, the server send back the custom page to client. When Mithril is loaded, it will redirect client to the default route because it can't know that route.
+
+```javascript
+m.route(document.body, "/", {
+  "/": homeComponent,
+  // [...]
+  "/:404...": errorPageComponent
+});
+ ```
+
 #### History state
 
 It's possible to take full advantage of the underlying `history.pushState` API to improve user's navigation experience. For example, an application could "remember" the state of a large form when the user leaves a page by navigating away, such that if the user pressed the back button in the browser, they'd have the form filled rather than a blank form.