mirror of
https://github.com/marko-js/marko.git
synced 2025-12-08 19:26:05 +00:00
Update prettier (#1062)
* update prettier * format files with new version of prettier
This commit is contained in:
Austin Kelleher
Michael Rawlings
parent
76137568f2
commit
d9805d0e28
16
.github/CODE_OF_CONDUCT.md
vendored
16
.github/CODE_OF_CONDUCT.md
vendored
@ -3,20 +3,20 @@
|
||||
This project adheres to the [eBay Code of Conduct](http://ebay.github.io/codeofconduct).
|
||||
By participating in this project you agree to abide by its terms.
|
||||
|
||||
* Be friendly and patient.
|
||||
- Be friendly and patient.
|
||||
|
||||
* Be welcoming: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
|
||||
- Be welcoming: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
|
||||
|
||||
* Be considerate: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
|
||||
- Be considerate: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
|
||||
|
||||
* Be respectful: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
|
||||
- Be respectful: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
|
||||
|
||||
* Be careful in the words that we choose: we are a community of professionals, and we conduct ourselves professionally.
|
||||
- Be careful in the words that we choose: we are a community of professionals, and we conduct ourselves professionally.
|
||||
|
||||
* Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable.
|
||||
- Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable.
|
||||
|
||||
* Try to understand why we disagree: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively.
|
||||
- Try to understand why we disagree: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively.
|
||||
|
||||
* Remember that we’re different. The strength of our community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
|
||||
- Remember that we’re different. The strength of our community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
|
||||
|
||||
Please visit http://ebay.github.io/codeofconduct for the full code of conduct.
|
||||
|
||||
62
.github/CONTRIBUTING.md
vendored
62
.github/CONTRIBUTING.md
vendored
@ -115,10 +115,10 @@ Comment on the issue and let us know you'd like to tackle it. If for some reason
|
||||
|
||||
Here's some to get started with:
|
||||
|
||||
* [good first issue](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22): great for new contributors
|
||||
* [help wanted](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) issues: won't be tackled in the near future by the maintainers... we need your help!
|
||||
* [unassigned](https://github.com/marko-js/marko/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Aassignee%20) issues: open issues that no one has claimed... yet
|
||||
* [has failing test](https://github.com/marko-js/marko/labels/has%20failing%20test) issues: open issues that already have a failing test case in the repo. make it pass!
|
||||
- [good first issue](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22): great for new contributors
|
||||
- [help wanted](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) issues: won't be tackled in the near future by the maintainers... we need your help!
|
||||
- [unassigned](https://github.com/marko-js/marko/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Aassignee%20) issues: open issues that no one has claimed... yet
|
||||
- [has failing test](https://github.com/marko-js/marko/labels/has%20failing%20test) issues: open issues that already have a failing test case in the repo. make it pass!
|
||||
|
||||
## Reporting bugs and other issues
|
||||
|
||||
@ -152,13 +152,13 @@ Once you post an issue, a maintainer will add one or more labels to it. Below is
|
||||
|
||||
Every issue should be assigned one of these.
|
||||
|
||||
* **bug**: A bug report
|
||||
* **unverified-bug**: A bug report that has not been verified
|
||||
* **feature**: A feature request
|
||||
* **question**: A question about how to do something in Marko
|
||||
* **community**: Related to community building, improving the contribution process, etc.
|
||||
* **tech debt**: Related to refactoring code, test structure, etc.
|
||||
* **docs**: Related to documentation/website
|
||||
- **bug**: A bug report
|
||||
- **unverified-bug**: A bug report that has not been verified
|
||||
- **feature**: A feature request
|
||||
- **question**: A question about how to do something in Marko
|
||||
- **community**: Related to community building, improving the contribution process, etc.
|
||||
- **tech debt**: Related to refactoring code, test structure, etc.
|
||||
- **docs**: Related to documentation/website
|
||||
|
||||
### Scope
|
||||
|
||||
@ -171,12 +171,12 @@ Every issue should be assigned one of these.
|
||||
|
||||
What part of the Marko stack does this issue apply to? In most cases there should only be one of these.
|
||||
|
||||
* **parser**: Relates to [`htmljs-parser`](https://github.com/marko-js/htmljs-parser)
|
||||
* **compiler**: Relates to the [compiler](../src/compiler) (server only)
|
||||
* **runtime**: Relates to the [runtime](../src/runtime) (isomorphic/universal)
|
||||
* **core-taglib**: Relates to [custom tags](../src/taglib) that ship with Marko
|
||||
* **components**: Relates to [components](../src/components)
|
||||
* **tools**: Relates to editor plugins, commandline tools, etc.
|
||||
- **parser**: Relates to [`htmljs-parser`](https://github.com/marko-js/htmljs-parser)
|
||||
- **compiler**: Relates to the [compiler](../src/compiler) (server only)
|
||||
- **runtime**: Relates to the [runtime](../src/runtime) (isomorphic/universal)
|
||||
- **core-taglib**: Relates to [custom tags](../src/taglib) that ship with Marko
|
||||
- **components**: Relates to [components](../src/components)
|
||||
- **tools**: Relates to editor plugins, commandline tools, etc.
|
||||
|
||||
### Status
|
||||
|
||||
@ -186,9 +186,9 @@ What part of the Marko stack does this issue apply to? In most cases there shoul
|
||||
|
||||
In many cases, additional _actions_ should be taken when applying one of these.
|
||||
|
||||
* **backlog**: Tasks planned to be worked on
|
||||
* **in progress**: This is currently being worked on.
|
||||
* **needs review**: This issue needs to be followed up on.
|
||||
- **backlog**: Tasks planned to be worked on
|
||||
- **in progress**: This is currently being worked on.
|
||||
- **needs review**: This issue needs to be followed up on.
|
||||
|
||||
### Reason closed
|
||||
|
||||
@ -199,12 +199,12 @@ In many cases, additional _actions_ should be taken when applying one of these.
|
||||
|
||||
|
||||
|
||||
* **resolved**: The question was answered, the bug was fixed, or the feature was implemented.
|
||||
* **duplicate**: Someone has already posted the same or a very similar issue. A comment should be added that references the original issue.
|
||||
* **declined**: This feature will not be implemented.
|
||||
* **not a bug**: This is not a bug, but either user error or intended behavior.
|
||||
* **inactivity**: There was not enough info to reproduce the bug or not enough interest in the feature to hash out an implementation plan and the conversation has stalled.
|
||||
* **no issue**: This wasn't so much an issue as a comment
|
||||
- **resolved**: The question was answered, the bug was fixed, or the feature was implemented.
|
||||
- **duplicate**: Someone has already posted the same or a very similar issue. A comment should be added that references the original issue.
|
||||
- **declined**: This feature will not be implemented.
|
||||
- **not a bug**: This is not a bug, but either user error or intended behavior.
|
||||
- **inactivity**: There was not enough info to reproduce the bug or not enough interest in the feature to hash out an implementation plan and the conversation has stalled.
|
||||
- **no issue**: This wasn't so much an issue as a comment
|
||||
|
||||
### Other
|
||||
|
||||
@ -214,8 +214,8 @@ In many cases, additional _actions_ should be taken when applying one of these.
|
||||
|
||||
|
||||
|
||||
* **good first issue**: Small tasks that would be good for first time contributors.
|
||||
* **help wanted**: Not on the roadmap, but we'd love for someone in the community to tackle it.
|
||||
* **blocked**: Cannot be completed until something else happens first. This should be described in a comment with a link to the blocking issue.
|
||||
* **needs more info**: The original poster needs to provide more information before action can be taken.
|
||||
* **user land**: Something that probably won't be added to core, but could be implemented/proved out as a separate module.
|
||||
- **good first issue**: Small tasks that would be good for first time contributors.
|
||||
- **help wanted**: Not on the roadmap, but we'd love for someone in the community to tackle it.
|
||||
- **blocked**: Cannot be completed until something else happens first. This should be described in a comment with a link to the blocking issue.
|
||||
- **needs more info**: The original poster needs to provide more information before action can be taken.
|
||||
- **user land**: Something that probably won't be added to core, but could be implemented/proved out as a separate module.
|
||||
|
||||
104
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
104
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
@ -1,53 +1,53 @@
|
||||
---
|
||||
---
|
||||
name: "\U0001F41BBug report"
|
||||
about: Something isn't working right
|
||||
---
|
||||
|
||||
### Marko Version: x.x.x
|
||||
|
||||
<!--- Provide the exact version of marko in which you see the bug. You can run `npm ls marko` to see this. -->
|
||||
|
||||
### Details
|
||||
|
||||
<!--- Provide a more detailed introduction to the issue itself, and why you consider it to be a bug. How has this bug affected you? What were you trying to accomplish? -->
|
||||
|
||||
### Expected Behavior
|
||||
|
||||
<!--- Tell us what should happen -->
|
||||
|
||||
### Actual Behavior
|
||||
|
||||
<!--- Tell us what happens instead -->
|
||||
|
||||
### Possible Fix
|
||||
|
||||
<!--- Not obligatory, but suggest a fix or reason for the bug -->
|
||||
|
||||
<details><summary>Additional Info</summary>
|
||||
|
||||
### Your Environment
|
||||
|
||||
<!-- Include as many relevant details about the environment you experienced the bug in -->
|
||||
|
||||
* Environment name and version (e.g. Chrome 39, node.js 5.4):
|
||||
* Operating System and version (desktop or mobile):
|
||||
* Link to your project:
|
||||
|
||||
### Steps to Reproduce
|
||||
|
||||
<!-- Provide a link to a live example -->
|
||||
|
||||
<!-- or an unambiguous set of steps to reproduce this bug -->
|
||||
|
||||
<!-- include code to reproduce, if relevant -->
|
||||
|
||||
1. first...
|
||||
2.
|
||||
3.
|
||||
4.
|
||||
|
||||
### Stack Trace
|
||||
|
||||
<!-- If an error is thrown, provide the stack trace here -->
|
||||
|
||||
</details>
|
||||
about: Something isn't working right
|
||||
---
|
||||
|
||||
### Marko Version: x.x.x
|
||||
|
||||
<!--- Provide the exact version of marko in which you see the bug. You can run `npm ls marko` to see this. -->
|
||||
|
||||
### Details
|
||||
|
||||
<!--- Provide a more detailed introduction to the issue itself, and why you consider it to be a bug. How has this bug affected you? What were you trying to accomplish? -->
|
||||
|
||||
### Expected Behavior
|
||||
|
||||
<!--- Tell us what should happen -->
|
||||
|
||||
### Actual Behavior
|
||||
|
||||
<!--- Tell us what happens instead -->
|
||||
|
||||
### Possible Fix
|
||||
|
||||
<!--- Not obligatory, but suggest a fix or reason for the bug -->
|
||||
|
||||
<details><summary>Additional Info</summary>
|
||||
|
||||
### Your Environment
|
||||
|
||||
<!-- Include as many relevant details about the environment you experienced the bug in -->
|
||||
|
||||
- Environment name and version (e.g. Chrome 39, node.js 5.4):
|
||||
- Operating System and version (desktop or mobile):
|
||||
- Link to your project:
|
||||
|
||||
### Steps to Reproduce
|
||||
|
||||
<!-- Provide a link to a live example -->
|
||||
|
||||
<!-- or an unambiguous set of steps to reproduce this bug -->
|
||||
|
||||
<!-- include code to reproduce, if relevant -->
|
||||
|
||||
1. first...
|
||||
2.
|
||||
3.
|
||||
4.
|
||||
|
||||
### Stack Trace
|
||||
|
||||
<!-- If an error is thrown, provide the stack trace here -->
|
||||
|
||||
</details>
|
||||
|
||||
46
.github/ISSUE_TEMPLATE/Feature_request.md
vendored
46
.github/ISSUE_TEMPLATE/Feature_request.md
vendored
@ -1,24 +1,24 @@
|
||||
---
|
||||
---
|
||||
name: "\U0001F680Feature request"
|
||||
about: Suggest an idea for this project
|
||||
---
|
||||
|
||||
### Description
|
||||
|
||||
<!--- Provide a detailed description of the change or addition you are proposing -->
|
||||
|
||||
### Why
|
||||
|
||||
<!--- Why is this change important to you? How would you use it? -->
|
||||
|
||||
<!--- How can it benefit other users? -->
|
||||
|
||||
### Possible Implementation & Open Questions
|
||||
|
||||
<!--- Not obligatory, but suggest an idea for implementing addition or change -->
|
||||
|
||||
<!--- What still needs to be discussed -->
|
||||
|
||||
### Is this something you're interested in working on?
|
||||
|
||||
<!--- Yes or no -->
|
||||
about: Suggest an idea for this project
|
||||
---
|
||||
|
||||
### Description
|
||||
|
||||
<!--- Provide a detailed description of the change or addition you are proposing -->
|
||||
|
||||
### Why
|
||||
|
||||
<!--- Why is this change important to you? How would you use it? -->
|
||||
|
||||
<!--- How can it benefit other users? -->
|
||||
|
||||
### Possible Implementation & Open Questions
|
||||
|
||||
<!--- Not obligatory, but suggest an idea for implementing addition or change -->
|
||||
|
||||
<!--- What still needs to be discussed -->
|
||||
|
||||
### Is this something you're interested in working on?
|
||||
|
||||
<!--- Yes or no -->
|
||||
|
||||
10
.github/PULL_REQUEST_TEMPLATE.md
vendored
10
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -18,10 +18,10 @@
|
||||
|
||||
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
|
||||
|
||||
* [ ] My code follows the code style of this project.
|
||||
* [ ] I have updated/added documentation affected by my changes.
|
||||
* [ ] I have read the **CONTRIBUTING** document.
|
||||
* [ ] I have added tests to cover my changes.
|
||||
* [ ] All new and existing tests passed.
|
||||
- [ ] My code follows the code style of this project.
|
||||
- [ ] I have updated/added documentation affected by my changes.
|
||||
- [ ] I have read the **CONTRIBUTING** document.
|
||||
- [ ] I have added tests to cover my changes.
|
||||
- [ ] All new and existing tests passed.
|
||||
|
||||
_Disclaimer: Contributions via GitHub pull requests are gladly accepted from their original author. Along with any pull requests, please state that the contribution is your original work and that you license the work to the project under the project's open source license. Whether or not you state this explicitly, by submitting any copyrighted material via pull request, email, or other means you agree to license the material under the project's open source license and warrant that you have the legal authority to do so._
|
||||
|
||||
782
CHANGELOG.md
782
CHANGELOG.md
File diff suppressed because it is too large
Load Diff
24
README.md
24
README.md
@ -13,12 +13,12 @@ Learn more on [markojs.com](http://markojs.com/), and even [Try Marko Online!](h
|
||||
|
||||
# Get Involved
|
||||
|
||||
* **Contributing**: Pull requests are welcome!
|
||||
* Read [`CONTRIBUTING.md`](.github/CONTRIBUTING.md) and check out our [bite-sized](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3Adifficulty%3Abite-sized) and [help-wanted](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3Astatus%3Ahelp-wanted) issues
|
||||
* Submit github issues for any feature enhancements, bugs or documentation problems
|
||||
* **Support**: Join our [gitter chat](https://gitter.im/marko-js/marko) to ask questions to get support from the maintainers and other Marko developers
|
||||
* Questions/comments can also be posted as [github issues](https://github.com/marko-js/marko/issues)
|
||||
* **Discuss**: Tweet using the `#MarkoJS` hashtag and follow [@MarkoDevTeam](https://twitter.com/MarkoDevTeam)
|
||||
- **Contributing**: Pull requests are welcome!
|
||||
- Read [`CONTRIBUTING.md`](.github/CONTRIBUTING.md) and check out our [bite-sized](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3Adifficulty%3Abite-sized) and [help-wanted](https://github.com/marko-js/marko/issues?q=is%3Aissue+is%3Aopen+label%3Astatus%3Ahelp-wanted) issues
|
||||
- Submit github issues for any feature enhancements, bugs or documentation problems
|
||||
- **Support**: Join our [gitter chat](https://gitter.im/marko-js/marko) to ask questions to get support from the maintainers and other Marko developers
|
||||
- Questions/comments can also be posted as [github issues](https://github.com/marko-js/marko/issues)
|
||||
- **Discuss**: Tweet using the `#MarkoJS` hashtag and follow [@MarkoDevTeam](https://twitter.com/MarkoDevTeam)
|
||||
|
||||
# Installation
|
||||
|
||||
@ -140,12 +140,12 @@ See [CHANGELOG.md](CHANGELOG.md)
|
||||
|
||||
# Maintainers
|
||||
|
||||
* [Patrick Steele-Idem](https://github.com/patrick-steele-idem) (Twitter: [@psteeleidem](http://twitter.com/psteeleidem))
|
||||
* [Michael Rawlings](https://github.com/mlrawlings) (Twitter: [@mlrawlings](https://twitter.com/mlrawlings))
|
||||
* [Phillip Gates-Idem](https://github.com/philidem/) (Twitter: [@philidem](https://twitter.com/philidem))
|
||||
* [Austin Kelleher](https://github.com/austinkelleher) (Twitter: [@AustinKelleher](https://twitter.com/AustinKelleher))
|
||||
* [Dylan Piercey](https://github.com/dylanpiercey) (Twitter: [@dylan_piercey](https://twitter.com/dylan_piercey))
|
||||
* [Martin Aberer](https://github.com/tindli) (Twitter: [@metaCoffee](https://twitter.com/metaCoffee))
|
||||
- [Patrick Steele-Idem](https://github.com/patrick-steele-idem) (Twitter: [@psteeleidem](http://twitter.com/psteeleidem))
|
||||
- [Michael Rawlings](https://github.com/mlrawlings) (Twitter: [@mlrawlings](https://twitter.com/mlrawlings))
|
||||
- [Phillip Gates-Idem](https://github.com/philidem/) (Twitter: [@philidem](https://twitter.com/philidem))
|
||||
- [Austin Kelleher](https://github.com/austinkelleher) (Twitter: [@AustinKelleher](https://twitter.com/AustinKelleher))
|
||||
- [Dylan Piercey](https://github.com/dylanpiercey) (Twitter: [@dylan_piercey](https://twitter.com/dylan_piercey))
|
||||
- [Martin Aberer](https://github.com/tindli) (Twitter: [@metaCoffee](https://twitter.com/metaCoffee))
|
||||
|
||||
# Code of Conduct
|
||||
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
var app = require("./components/app");
|
||||
app
|
||||
.renderSync({
|
||||
name: "Frank",
|
||||
colors: ["red", "green", "blue"]
|
||||
})
|
||||
.appendTo(document.body);
|
||||
app.renderSync({
|
||||
name: "Frank",
|
||||
colors: ["red", "green", "blue"]
|
||||
}).appendTo(document.body);
|
||||
|
||||
@ -12,9 +12,9 @@ With Marko, the DOM output of a UI component is based on input properties and a
|
||||
|
||||
Marko makes it easy to to co-locate your component's class and styles with the HTML view that they correspond to. The following are the key part of any UI component:
|
||||
|
||||
* **View** - The HTML template for your UI component. Receives input properties and states and renders to either HTML (server-side) or virtual DOM nodes (browser-side)
|
||||
* **Client-side behavior** - Implemented as a JavaScript class with methods and properties to provide initialization, event handling (including DOM events, custom events and lifecycle events) and state management
|
||||
* **Styling** - Cascading StyleSheet with support for CSS preprocessors such as Less or Sass
|
||||
- **View** - The HTML template for your UI component. Receives input properties and states and renders to either HTML (server-side) or virtual DOM nodes (browser-side)
|
||||
- **Client-side behavior** - Implemented as a JavaScript class with methods and properties to provide initialization, event handling (including DOM events, custom events and lifecycle events) and state management
|
||||
- **Styling** - Cascading StyleSheet with support for CSS preprocessors such as Less or Sass
|
||||
|
||||
## Server-side rendering
|
||||
|
||||
@ -250,7 +250,7 @@ class {
|
||||
Any string that represents a valid JavaScript identifier is allowed for the event handler method name and it can be a JavaScript expression. The following arguments are passed to the handler method when the event is fired:
|
||||
|
||||
1. `...args` - Any extra arguments bind are _prepended_ to the arguments passed to the component's handler method
|
||||
* For example: `on-click('onButtonClick', arg1, arg2)` → `onButtonClick(arg1, arg2, event, el)`)
|
||||
- For example: `on-click('onButtonClick', arg1, arg2)` → `onButtonClick(arg1, arg2, event, el)`)
|
||||
2. `event` - The native DOM event
|
||||
3. `el` - The DOM element that the event listener was attached to
|
||||
|
||||
@ -800,12 +800,12 @@ Adds a one time listener function for the event named eventName. The next time e
|
||||
|
||||
Marko defines six distinct lifecycle events:
|
||||
|
||||
* `create`
|
||||
* `input`
|
||||
* `render`
|
||||
* `mount`
|
||||
* `update`
|
||||
* `destroy`
|
||||
- `create`
|
||||
- `input`
|
||||
- `render`
|
||||
- `mount`
|
||||
- `update`
|
||||
- `destroy`
|
||||
|
||||
These events are emitted at specific points over the lifecycle of a component as shown below:
|
||||
|
||||
|
||||
@ -405,27 +405,27 @@ $ var personPromise = new Promise((resolve, reject) => {
|
||||
|
||||
Advanced implementation:
|
||||
|
||||
* `<await>` tag signature
|
||||
* Basic usage: `<await(results from dataProvider)>...</await>`
|
||||
* Optional attributes
|
||||
* client-reorder `boolean`
|
||||
* arg `expression`
|
||||
* arg-\* `string`
|
||||
* method `string`
|
||||
* timeout `integer`
|
||||
* timeout-message `string`
|
||||
* error-message `string`
|
||||
* placeholder `string`
|
||||
* renderTimeout `function`
|
||||
* renderError `function`
|
||||
* renderPlaceholder `function`
|
||||
* name `string`
|
||||
* scope `expression`
|
||||
* show-after `string`
|
||||
* Optional child tags
|
||||
* `<await-placeholder>Loading...</await-placeholder>`
|
||||
* `<await-timeout>Request timed out</await-timeout>`
|
||||
* `<await-error>Request errored</await-error>`
|
||||
- `<await>` tag signature
|
||||
- Basic usage: `<await(results from dataProvider)>...</await>`
|
||||
- Optional attributes
|
||||
- client-reorder `boolean`
|
||||
- arg `expression`
|
||||
- arg-\* `string`
|
||||
- method `string`
|
||||
- timeout `integer`
|
||||
- timeout-message `string`
|
||||
- error-message `string`
|
||||
- placeholder `string`
|
||||
- renderTimeout `function`
|
||||
- renderError `function`
|
||||
- renderPlaceholder `function`
|
||||
- name `string`
|
||||
- scope `expression`
|
||||
- show-after `string`
|
||||
- Optional child tags
|
||||
- `<await-placeholder>Loading...</await-placeholder>`
|
||||
- `<await-timeout>Request timed out</await-timeout>`
|
||||
- `<await-error>Request errored</await-error>`
|
||||
|
||||
## Comments
|
||||
|
||||
@ -494,9 +494,9 @@ Alternatively, the `<marko-compiler-options>` tag may be used to configure white
|
||||
|
||||
The `marko-body` attribute can be used to control how body content is parsed. The following values are supported:
|
||||
|
||||
* `html` - Body content will be parsed HTML (the default)
|
||||
* `static-text` - Body content will be parsed as static text (HTML tags will be ignored). Placeholders will be ignored.
|
||||
* `parsed-text` - Body content will be parsed as text (HTML tags will be ignored). Placeholders will not be ignored.
|
||||
- `html` - Body content will be parsed HTML (the default)
|
||||
- `static-text` - Body content will be parsed as static text (HTML tags will be ignored). Placeholders will be ignored.
|
||||
- `parsed-text` - Body content will be parsed as text (HTML tags will be ignored). Placeholders will not be ignored.
|
||||
|
||||
_input.marko_
|
||||
|
||||
|
||||
@ -28,9 +28,9 @@ pages/
|
||||
|
||||
When compiling the template at `pages/home/index.marko`, the following tags would be found:
|
||||
|
||||
* `<app-header>`
|
||||
* `<app-footer>`
|
||||
* `<home-banner>`
|
||||
- `<app-header>`
|
||||
- `<app-footer>`
|
||||
- `<home-banner>`
|
||||
|
||||
So now, instead of needing to specify a path:
|
||||
|
||||
|
||||
@ -4,36 +4,36 @@
|
||||
|
||||
[Documentation](https://atom.io/packages/language-marko)
|
||||
|
||||
* Syntax highlighting
|
||||
* Tag matching
|
||||
* Tag and attribute autocompletion
|
||||
* Code snippets
|
||||
* Hyperclick (clickable tags and attributes)
|
||||
* Prettyprinting ([marko-prettyprint](https://github.com/marko-js/marko-prettyprint) is used internally)
|
||||
- Syntax highlighting
|
||||
- Tag matching
|
||||
- Tag and attribute autocompletion
|
||||
- Code snippets
|
||||
- Hyperclick (clickable tags and attributes)
|
||||
- Prettyprinting ([marko-prettyprint](https://github.com/marko-js/marko-prettyprint) is used internally)
|
||||
|
||||
## Visual Studio Code
|
||||
|
||||
[Documentation](https://marketplace.visualstudio.com/items?itemName=pcanella.marko)
|
||||
|
||||
* Syntax highlighting
|
||||
- Syntax highlighting
|
||||
|
||||
## Sublime
|
||||
|
||||
[Documentation](https://github.com/merwan7/sublime-marko)
|
||||
|
||||
* Syntax highlighting
|
||||
- Syntax highlighting
|
||||
|
||||
## WebStorm
|
||||
|
||||
[Documentation](https://github.com/marko-js/marko-tmbundle)
|
||||
|
||||
* Syntax highlighting
|
||||
- Syntax highlighting
|
||||
|
||||
## TextMate
|
||||
|
||||
[Documentation](https://github.com/marko-js/marko-tmbundle)
|
||||
|
||||
* Syntax highlighting
|
||||
- Syntax highlighting
|
||||
|
||||
## CodeMirror
|
||||
|
||||
|
||||
@ -105,7 +105,7 @@ browser-refresh server.js
|
||||
|
||||
For many use cases, the combination of `lasso-marko` and `@lasso/marko-taglib` is sufficient to render and bundle components without the need for explicit `browser.json` files. For more advanced use cases, the following bundle types may be defined in a `browser.json` for Lasso.
|
||||
|
||||
* **`marko-dependencies`**: (provided by `lasso-marko`)
|
||||
- **`marko-dependencies`**: (provided by `lasso-marko`)
|
||||
Includes all the dependencies needed by template and the code to register all components that would be rendered by the template. It does not automatically initialize the component, so is most useful if you need to initialize components manually.
|
||||
|
||||
```json
|
||||
@ -115,7 +115,7 @@ For many use cases, the combination of `lasso-marko` and `@lasso/marko-taglib` i
|
||||
}
|
||||
```
|
||||
|
||||
* **`marko-hydrate`**: (provided by `lasso-marko`)
|
||||
- **`marko-hydrate`**: (provided by `lasso-marko`)
|
||||
Includes all the dependencies needed by template and the code to register all components that would be rendered by the template. This also includes the code to initialize the rendered components. Including this bundle on the page will automatically hydrate server rendered components.
|
||||
|
||||
```json
|
||||
@ -125,7 +125,7 @@ For many use cases, the combination of `lasso-marko` and `@lasso/marko-taglib` i
|
||||
}
|
||||
```
|
||||
|
||||
* **`package`**:
|
||||
- **`package`**:
|
||||
A collection of dependencies. `browser.json` is the most common package type.
|
||||
It could be used to point to another `browser.json` from within one component's `browser.json`.
|
||||
Typically also used when the dependencies of the referred `browser.json` have to be packaged inline.
|
||||
@ -135,7 +135,7 @@ For many use cases, the combination of `lasso-marko` and `@lasso/marko-taglib` i
|
||||
"path": "src/ui-modules/show-diag/browser.json"
|
||||
}
|
||||
```
|
||||
* **`require`**:
|
||||
- **`require`**:
|
||||
If a javascript file has to be wrapped over for its common JS syntax, to a browser understandable format.
|
||||
```json
|
||||
{
|
||||
|
||||
@ -122,10 +122,10 @@ function render(data, out) {
|
||||
|
||||
The VDOM output allows optimizations that were previously not possible:
|
||||
|
||||
* Static subtrees are pulled into variables that are only initialized once and reused for every render
|
||||
* Static attributes that are on dynamic elements are pulled out to static variables
|
||||
* Diffing is skipped when comparing static subtrees
|
||||
* Diffing is skipped when comparing static attributes
|
||||
- Static subtrees are pulled into variables that are only initialized once and reused for every render
|
||||
- Static attributes that are on dynamic elements are pulled out to static variables
|
||||
- Diffing is skipped when comparing static subtrees
|
||||
- Diffing is skipped when comparing static attributes
|
||||
|
||||
Our benchmarks show a significant improvement in rendering time and we are consistently outperforming React/Preact/Inferno, Vue and other UI libraries.
|
||||
|
||||
@ -137,11 +137,11 @@ You will no longer need to install `marko-widgets` as an external library, and t
|
||||
|
||||
### Improved component lifecycle methods ([#396](https://github.com/marko-js/marko/issues/396))
|
||||
|
||||
* `getInitialState()` ➔ `onInput(input)`
|
||||
* `getComponentConfig()` ➔ `onInput(input)`
|
||||
* `init(config)` ➔ `onMount()`
|
||||
* `getTemplateData(input, state)` ➔ (no longer needed)
|
||||
* `getInitialProps(input)` ➔ (no longer needed)
|
||||
- `getInitialState()` ➔ `onInput(input)`
|
||||
- `getComponentConfig()` ➔ `onInput(input)`
|
||||
- `init(config)` ➔ `onMount()`
|
||||
- `getTemplateData(input, state)` ➔ (no longer needed)
|
||||
- `getInitialProps(input)` ➔ (no longer needed)
|
||||
|
||||
```js
|
||||
class {
|
||||
@ -272,17 +272,17 @@ require("./template.marko")
|
||||
|
||||
### Less Boilerplate
|
||||
|
||||
* Removed: `w-bind`
|
||||
* Removed: `w-extend`
|
||||
* Removed: `require('marko-widgets').defineComponent(...)`
|
||||
* Removed: `require('marko-widgets').defineWidget(...)`
|
||||
* Removed: `require('marko-widgets').defineRenderer(...)`
|
||||
* Removed: `w-body` (use `<include()>` instead)
|
||||
* `w-on*="handleSomeEvent"` --> `on*('handleSomeEvent')`
|
||||
* `w-id` --> `key`
|
||||
* `w-for` --> `for-key`
|
||||
* `w-preserve` --> `no-update`
|
||||
* `class="foo" w-preserve-attrs="class"` --> `class:no-update="foo"`
|
||||
- Removed: `w-bind`
|
||||
- Removed: `w-extend`
|
||||
- Removed: `require('marko-widgets').defineComponent(...)`
|
||||
- Removed: `require('marko-widgets').defineWidget(...)`
|
||||
- Removed: `require('marko-widgets').defineRenderer(...)`
|
||||
- Removed: `w-body` (use `<include()>` instead)
|
||||
- `w-on*="handleSomeEvent"` --> `on*('handleSomeEvent')`
|
||||
- `w-id` --> `key`
|
||||
- `w-for` --> `for-key`
|
||||
- `w-preserve` --> `no-update`
|
||||
- `class="foo" w-preserve-attrs="class"` --> `class:no-update="foo"`
|
||||
|
||||
Some of these things are described in more detail later in this document.
|
||||
|
||||
@ -380,9 +380,9 @@ static {
|
||||
|
||||
### Template variables
|
||||
|
||||
* `data` --> `input` - References the input object (should be treated as immutable)
|
||||
* Introduced `state` - References the components raw state object (for components only)
|
||||
* Introduced `component` - References the component instance (for components only)
|
||||
- `data` --> `input` - References the input object (should be treated as immutable)
|
||||
- Introduced `state` - References the components raw state object (for components only)
|
||||
- Introduced `component` - References the component instance (for components only)
|
||||
|
||||
## Other Improvements
|
||||
|
||||
|
||||
@ -113,24 +113,24 @@ Online](http://markojs.com/try-online/?gist=8fe46bc5866605aca0dfeec202604011)</s
|
||||
|
||||
Marko and React have the following in common:
|
||||
|
||||
* UI component-based
|
||||
* JavaScript and HTML markup can be intertwined
|
||||
* No restrictions on JavaScript (use ES5 or ES2015+, your choice)
|
||||
* Virtual DOM rendering in the browser
|
||||
* DOM diffing/patching is used to reconcile views
|
||||
* Both support keyed element matching
|
||||
* UI components can have input properties
|
||||
* UI components can have internal state
|
||||
* Changes to state trigger an asynchronous update to the DOM
|
||||
* Updates to the DOM are batched
|
||||
* Compatible with central application state stores such as Redux and MobX
|
||||
* UI components can be embedded using custom tags
|
||||
* Declarative event binding (no `domEl.addEventListener()` needed)
|
||||
* Support for all DOM events
|
||||
* Event delegation utilized internally for DOM events that bubble
|
||||
* IE9+ support
|
||||
* Similar lifecycle events for UI components
|
||||
* JSX and Marko both compile to JavaScript
|
||||
- UI component-based
|
||||
- JavaScript and HTML markup can be intertwined
|
||||
- No restrictions on JavaScript (use ES5 or ES2015+, your choice)
|
||||
- Virtual DOM rendering in the browser
|
||||
- DOM diffing/patching is used to reconcile views
|
||||
- Both support keyed element matching
|
||||
- UI components can have input properties
|
||||
- UI components can have internal state
|
||||
- Changes to state trigger an asynchronous update to the DOM
|
||||
- Updates to the DOM are batched
|
||||
- Compatible with central application state stores such as Redux and MobX
|
||||
- UI components can be embedded using custom tags
|
||||
- Declarative event binding (no `domEl.addEventListener()` needed)
|
||||
- Support for all DOM events
|
||||
- Event delegation utilized internally for DOM events that bubble
|
||||
- IE9+ support
|
||||
- Similar lifecycle events for UI components
|
||||
- JSX and Marko both compile to JavaScript
|
||||
|
||||
### Differences
|
||||
|
||||
@ -138,106 +138,106 @@ At a high level here are some differences:
|
||||
|
||||
#### Differences in rendering
|
||||
|
||||
* **Improved performance:** Marko renders to a virtual DOM in the browser and
|
||||
- **Improved performance:** Marko renders to a virtual DOM in the browser and
|
||||
directly to an HTML stream on the server (Marko supports multiple compilation
|
||||
targets).
|
||||
* **Improved performance:** Marko supports asynchronous rendering with [early
|
||||
- **Improved performance:** Marko supports asynchronous rendering with [early
|
||||
flushing of
|
||||
HTML](http://www.ebaytechblog.com/2014/12/08/async-fragments-rediscovering-progressive-html-rendering-with-marko/)
|
||||
for improvements in actual and perceived page load times.
|
||||
* **Improved performance: **React requires an additional client-side re-render if
|
||||
- **Improved performance: **React requires an additional client-side re-render if
|
||||
a page is initially rendered on the server while Marko does not.
|
||||
* **Improved ease of use: **Marko automatically serializes UI component state and
|
||||
- **Improved ease of use: **Marko automatically serializes UI component state and
|
||||
input down to the browser so that the browser can pick up right where the server
|
||||
left off.
|
||||
* **Improved ease of use: **Marko is suitable for rendering an entire HTML page on
|
||||
- **Improved ease of use: **Marko is suitable for rendering an entire HTML page on
|
||||
the server with support for tags such as `<doctype>` and `<html>`
|
||||
|
||||
#### Differences in syntax
|
||||
|
||||
* **Improved ease of use: **Marko uses the
|
||||
- **Improved ease of use: **Marko uses the
|
||||
[HTML-JS](http://markojs.com/docs/syntax/) syntax and the
|
||||
[JSX](https://facebook.github.io/react/docs/jsx-in-depth.html) syntax is offered
|
||||
for React.
|
||||
* **Improved ease of use: **Marko supports both a concise syntax and a familiar
|
||||
- **Improved ease of use: **Marko supports both a concise syntax and a familiar
|
||||
HTML syntax.
|
||||
* **Improved ease of use: **JSX requires strict XML while Marko aligns with less
|
||||
- **Improved ease of use: **JSX requires strict XML while Marko aligns with less
|
||||
strict HTML that web developers are used to.
|
||||
* **Improved ease of use: **With Marko, _all_ HTML attribute values are parsed as
|
||||
- **Improved ease of use: **With Marko, _all_ HTML attribute values are parsed as
|
||||
JavaScript expressions.
|
||||
* **Improved ease of use: **Marko supports simple directives for conditionals,
|
||||
- **Improved ease of use: **Marko supports simple directives for conditionals,
|
||||
looping, etc.
|
||||
* **JSX limitation: **JSX is “just JavaScript” but requires expressions that
|
||||
- **JSX limitation: **JSX is “just JavaScript” but requires expressions that
|
||||
preclude the usage of JavaScript statements such as in certain places.
|
||||
|
||||
#### Differences in compilation
|
||||
|
||||
* **Improved performance: **Marko supports multiple compilation outputs (Marko
|
||||
- **Improved performance: **Marko supports multiple compilation outputs (Marko
|
||||
VDOM and HTML streaming are currently supported).
|
||||
* **Improved ease of use: **Marko compiles UI components to JavaScript modules
|
||||
- **Improved ease of use: **Marko compiles UI components to JavaScript modules
|
||||
that export a rendering API.
|
||||
* **Expanded capabilities: **Marko supports a robust API for controlling how
|
||||
- **Expanded capabilities: **Marko supports a robust API for controlling how
|
||||
custom tags and custom attributes get compiled and it supports compile-time
|
||||
transforms based on a friendly Abstract Syntax Tree (AST).
|
||||
* **Improved performance: **JSX is just syntactic sugar that translates elements
|
||||
- **Improved performance: **JSX is just syntactic sugar that translates elements
|
||||
to `createElement()` function calls while the Marko compiler has full control over how things are
|
||||
compiled and optimized.
|
||||
* **Improved ease of use: **React requires all UI components to be explicitly
|
||||
- **Improved ease of use: **React requires all UI components to be explicitly
|
||||
imported before they can be used as custom tags while Marko supports both
|
||||
explicit importing and implicit importing.
|
||||
* **Improved performance: **Marko has a modular runtime and the compiler generates
|
||||
- **Improved performance: **Marko has a modular runtime and the compiler generates
|
||||
code that only imports the parts of the Marko runtime that are needed for much
|
||||
smaller builds.
|
||||
* **Improved ease of use: **Marko supports optional compile-time checks to ensure
|
||||
- **Improved ease of use: **Marko supports optional compile-time checks to ensure
|
||||
that only allowed attributes are passed to custom tags. (React `PropTypes` only provide
|
||||
validation at render-time)
|
||||
* **Improved ease of use: **Marko validates _all_ tag names at compile-time.
|
||||
* **Improved ease of use: **Marko provides its own compiler that integrates with
|
||||
- **Improved ease of use: **Marko validates _all_ tag names at compile-time.
|
||||
- **Improved ease of use: **Marko provides its own compiler that integrates with
|
||||
Node.js and JavaScript module bundlers while React JSX requires babel and custom
|
||||
babel transforms.
|
||||
|
||||
#### Differences in UI components
|
||||
|
||||
* **Reduced boilerplate: **No explicit extending of JavaScript classes in Marko
|
||||
- **Reduced boilerplate: **No explicit extending of JavaScript classes in Marko
|
||||
(in contrast to `class Counter extends React.Component` in React).
|
||||
* **Improved ease of use: **Modifications to UI component state are synchronous
|
||||
- **Improved ease of use: **Modifications to UI component state are synchronous
|
||||
with Marko while [the rules for React are more
|
||||
complicated](https://facebook.github.io/react/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous).
|
||||
* **Improved ease of use: **Marko watches UI component state objects to allow
|
||||
- **Improved ease of use: **Marko watches UI component state objects to allow
|
||||
state to be modified directly (e.g., `this.state.count++`).
|
||||
* **Improved ease of use: **Marko supports single-file UI components combining
|
||||
- **Improved ease of use: **Marko supports single-file UI components combining
|
||||
JavaScript behavior, CSS styling (with support for CSS preprocessors) and HTML
|
||||
markup. (React requires using one of the many [CSS in JS
|
||||
solutions](https://github.com/MicheleBertoli/css-in-js) if you want styles in
|
||||
the same file as your component and there is no standard in the community)
|
||||
* **Improved maintainability: **Marko supports a seamless transition from a
|
||||
- **Improved maintainability: **Marko supports a seamless transition from a
|
||||
single-file UI component to a multi-file UI component.
|
||||
* **Improved performance:** Marko assumes UI components are pure by default and
|
||||
- **Improved performance:** Marko assumes UI components are pure by default and
|
||||
skips re-rendering when input properties and state are unchanged (React requires
|
||||
extending
|
||||
[React.PureComponent](https://facebook.github.io/react/docs/react-api.html#react.purecomponent)).
|
||||
|
||||
#### Differences in event systems
|
||||
|
||||
* **Reduced complexity: **React utilizes [synthetic
|
||||
- **Reduced complexity: **React utilizes [synthetic
|
||||
events](https://facebook.github.io/react/docs/events.html) while Marko utilizes
|
||||
real DOM events.
|
||||
* **Improved ease of use: **Custom events are emitted using the [EventEmitter
|
||||
- **Improved ease of use: **Custom events are emitted using the [EventEmitter
|
||||
API](https://nodejs.org/api/events.html) in Marko (e.g., `this.emit('myCustomEvent', arg1, arg2)`).
|
||||
* **Improved ease of use: **Marko has a consistent approach for listening to both
|
||||
- **Improved ease of use: **Marko has a consistent approach for listening to both
|
||||
native DOM events and custom events.
|
||||
* **Improved ease of use: **React requires passing around `Function` references for custom
|
||||
- **Improved ease of use: **React requires passing around `Function` references for custom
|
||||
events while Marko automatically delegates emitted custom events to event
|
||||
handler methods on components.
|
||||
* **Improved ease of use: **Marko provides a simple mechanism for binding
|
||||
- **Improved ease of use: **Marko provides a simple mechanism for binding
|
||||
additional arguments to event handler methods and `this` will be the component
|
||||
instance.
|
||||
|
||||
#### Differences in compatibility
|
||||
|
||||
* **Marko limitation: **Marko has no support for native mobile similar to React
|
||||
- **Marko limitation: **Marko has no support for native mobile similar to React
|
||||
Native (although with Marko VDOM rendering, this is possible).
|
||||
* **Marko limitation: **Marko requires a JavaScript module bundler (such as
|
||||
- **Marko limitation: **Marko requires a JavaScript module bundler (such as
|
||||
[Lasso](http://markojs.com/docs/lasso/),
|
||||
[Webpack](http://markojs.com/docs/webpack/),
|
||||
[Rollup](http://markojs.com/docs/rollup/) or
|
||||
@ -828,21 +828,21 @@ your code readable.
|
||||
Here are just a few reasons you should consider using
|
||||
[Marko](http://markojs.com/) over React:
|
||||
|
||||
* Marko requires much less boilerplate.
|
||||
* Marko has much better performance based on our benchmarks.
|
||||
* Marko offers a clean and powerful syntax that aligns with HTML while also
|
||||
- Marko requires much less boilerplate.
|
||||
- Marko has much better performance based on our benchmarks.
|
||||
- Marko offers a clean and powerful syntax that aligns with HTML while also
|
||||
allowing the full power of JavaScript.
|
||||
* Marko has much less complexity and a very small runtime.
|
||||
* Marko has a much lower page weight for faster page loads.
|
||||
* Marko has strong integrations with Node.js.
|
||||
* Marko allows for extremely powerful IDE and editor plugins (see the [Marko
|
||||
- Marko has much less complexity and a very small runtime.
|
||||
- Marko has a much lower page weight for faster page loads.
|
||||
- Marko has strong integrations with Node.js.
|
||||
- Marko allows for extremely powerful IDE and editor plugins (see the [Marko
|
||||
plugin for Atom](https://github.com/marko-js/atom-language-marko) as an
|
||||
example).
|
||||
* Marko has a powerful compiler that allows new features to be added without
|
||||
- Marko has a powerful compiler that allows new features to be added without
|
||||
introducing bloat.
|
||||
* eBay relies heavily on Marko and it is being used to build ebay.com (including
|
||||
- eBay relies heavily on Marko and it is being used to build ebay.com (including
|
||||
the mobile web).
|
||||
* Marko has a strong and growing community on
|
||||
- Marko has a strong and growing community on
|
||||
[GitHub](https://github.com/marko-js/marko) and in
|
||||
[Gitter](https://gitter.im/marko-js/marko).
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
The files in this directory will be automatically generated by jsdoc.
|
||||
|
||||
* AST Nodes
|
||||
* Runtime API
|
||||
* Compiler API
|
||||
* CompileContext API
|
||||
* Builder API
|
||||
* CodeGenerator API
|
||||
* AsyncWriter API
|
||||
* AsyncVDOMBuilder API
|
||||
- AST Nodes
|
||||
- Runtime API
|
||||
- Compiler API
|
||||
- CompileContext API
|
||||
- Builder API
|
||||
- CodeGenerator API
|
||||
- AsyncWriter API
|
||||
- AsyncVDOMBuilder API
|
||||
|
||||
@ -24,10 +24,10 @@ module.exports = function(req) {
|
||||
|
||||
> **ProTip:** Marko also provides server-side framework integrations:
|
||||
>
|
||||
> * [express](./express.md)
|
||||
> * [hapi](./hapi.md)
|
||||
> * [koa](./koa.md)
|
||||
> * [huncwot](./huncwot.md)
|
||||
> - [express](./express.md)
|
||||
> - [hapi](./hapi.md)
|
||||
> - [koa](./koa.md)
|
||||
> - [huncwot](./huncwot.md)
|
||||
|
||||
## UI Bootstrapping
|
||||
|
||||
@ -67,8 +67,8 @@ _routes/index/template.marko_
|
||||
|
||||
> **ProTip:** We have provided some sample apps to help you get started with Marko + Lasso
|
||||
>
|
||||
> * [marko-lasso](https://github.com/marko-js-samples/marko-lasso)
|
||||
> * [ui-components-playground](https://github.com/marko-js-samples/ui-components-playground)
|
||||
> - [marko-lasso](https://github.com/marko-js-samples/marko-lasso)
|
||||
> - [ui-components-playground](https://github.com/marko-js-samples/ui-components-playground)
|
||||
|
||||
### Bootstrapping: Non-Lasso
|
||||
|
||||
@ -94,9 +94,9 @@ require("marko/components").init();
|
||||
|
||||
> **ProTip:** We have provided some sample apps to help you get started:
|
||||
>
|
||||
> * [marko-webpack](https://github.com/marko-js-samples/marko-webpack)
|
||||
> * [marko-browserify](https://github.com/marko-js-samples/marko-browserify)
|
||||
> * [marko-rollup](https://github.com/marko-js-samples/marko-rollup)
|
||||
> - [marko-webpack](https://github.com/marko-js-samples/marko-webpack)
|
||||
> - [marko-browserify](https://github.com/marko-js-samples/marko-browserify)
|
||||
> - [marko-rollup](https://github.com/marko-js-samples/marko-rollup)
|
||||
|
||||
# Serialization
|
||||
|
||||
@ -122,11 +122,11 @@ class {
|
||||
|
||||
There are some caveats associated with rendering a page on the server:
|
||||
|
||||
* The UI component data for top-level UI components must be serializable:
|
||||
* Only simple objects, numbers, strings, booleans, arrays and `Date` objects are serializable
|
||||
* Functions are not serializable
|
||||
* Care should be taken to avoid having Marko serialize too much data
|
||||
* None of the data in `out.global` is serialized by default, but this can be changed as shown below
|
||||
- The UI component data for top-level UI components must be serializable:
|
||||
- Only simple objects, numbers, strings, booleans, arrays and `Date` objects are serializable
|
||||
- Functions are not serializable
|
||||
- Care should be taken to avoid having Marko serialize too much data
|
||||
- None of the data in `out.global` is serialized by default, but this can be changed as shown below
|
||||
|
||||
## Serializing globals
|
||||
|
||||
|
||||
@ -123,8 +123,8 @@ Compared to solutions based on JSX that exclusively do virtual DOM rendering,
|
||||
Marko has a huge advantage for server-side rendering. When rendering to a
|
||||
virtual DOM tree on the server it’s a two-step process to render HTML:
|
||||
|
||||
* First pass to produce an entire virtual DOM tree in memory
|
||||
* Second pass to serialize the virtual DOM tree to an HTML string that can then be
|
||||
- First pass to produce an entire virtual DOM tree in memory
|
||||
- Second pass to serialize the virtual DOM tree to an HTML string that can then be
|
||||
sent over the wire (this requires traversing the entire tree structure)
|
||||
|
||||
In contrast, Marko renders directly to an HTML stream in a single pass. There is
|
||||
|
||||
6
package-lock.json
generated
6
package-lock.json
generated
@ -7280,9 +7280,9 @@
|
||||
"dev": true
|
||||
},
|
||||
"prettier": {
|
||||
"version": "1.12.1",
|
||||
"resolved": "https://registry.npmjs.org/prettier/-/prettier-1.12.1.tgz",
|
||||
"integrity": "sha1-wa0g6APndJ+vkFpAnSNn4Gu+cyU=",
|
||||
"version": "1.13.5",
|
||||
"resolved": "https://registry.npmjs.org/prettier/-/prettier-1.13.5.tgz",
|
||||
"integrity": "sha512-4M90mfvLz6yRf2Dhzd+xPIE6b4xkI8nHMJhsSm9IlfG17g6wujrrm7+H1X8x52tC4cSNm6HmuhCUSNe6Hd5wfw==",
|
||||
"dev": true
|
||||
},
|
||||
"pretty-format": {
|
||||
|
||||
@ -91,7 +91,7 @@
|
||||
"mocha": "^5.0.1",
|
||||
"nyc": "^10.3.2",
|
||||
"open": "0.0.5",
|
||||
"prettier": "^1.12.1",
|
||||
"prettier": "^1.13.5",
|
||||
"request": "^2.72.0",
|
||||
"semver": "^5.4.1",
|
||||
"shelljs": "^0.7.7",
|
||||
|
||||
@ -41,11 +41,9 @@ module.exports = function(target, renderer) {
|
||||
}
|
||||
|
||||
if (callback) {
|
||||
out
|
||||
.on("finish", function() {
|
||||
callback(null, out.toString(), out);
|
||||
})
|
||||
.once("error", callback);
|
||||
out.on("finish", function() {
|
||||
callback(null, out.toString(), out);
|
||||
}).once("error", callback);
|
||||
|
||||
return safeRender(render, localData, out, true);
|
||||
} else {
|
||||
|
||||
@ -11,14 +11,12 @@ exports.check = function(marko, markoCompiler, expect, snapshot, done) {
|
||||
var runtimeHtml = require("marko/src/html");
|
||||
|
||||
var out = runtimeHtml.createWriter(stream);
|
||||
out
|
||||
.on("end", function() {
|
||||
snapshot(output);
|
||||
done();
|
||||
})
|
||||
.on("error", function(e) {
|
||||
done(e);
|
||||
});
|
||||
out.on("end", function() {
|
||||
snapshot(output);
|
||||
done();
|
||||
}).on("error", function(e) {
|
||||
done(e);
|
||||
});
|
||||
|
||||
var template = marko.load(nodePath.join(__dirname, "template.marko"));
|
||||
|
||||
|
||||
@ -4,14 +4,12 @@ exports.check = function(marko, markoCompiler, expect, snapshot, done) {
|
||||
var runtimeHtml = require("marko/html");
|
||||
|
||||
var out = runtimeHtml.createWriter();
|
||||
out
|
||||
.on("finish", function(result) {
|
||||
snapshot(result.getOutput());
|
||||
done();
|
||||
})
|
||||
.on("error", function(e) {
|
||||
done(e);
|
||||
});
|
||||
out.on("finish", function(result) {
|
||||
snapshot(result.getOutput());
|
||||
done();
|
||||
}).on("error", function(e) {
|
||||
done(e);
|
||||
});
|
||||
|
||||
var template = marko.load(nodePath.join(__dirname, "template.marko"));
|
||||
template.render(
|
||||
|
||||
@ -6,19 +6,17 @@ exports.check = function(marko, markoCompiler, expect, helpers, done) {
|
||||
var events = [];
|
||||
var error;
|
||||
|
||||
out
|
||||
.on("error", function(_error) {
|
||||
events.push("error");
|
||||
error = _error;
|
||||
})
|
||||
.on("finish", function() {
|
||||
events.push("finish");
|
||||
out.on("error", function(_error) {
|
||||
events.push("error");
|
||||
error = _error;
|
||||
}).on("finish", function() {
|
||||
events.push("finish");
|
||||
|
||||
expect(events).to.deep.equal(["error", "finish"]);
|
||||
expect(error != null).to.equal(true);
|
||||
expect(error.toString()).to.contain("invalid");
|
||||
expect(events).to.deep.equal(["error", "finish"]);
|
||||
expect(error != null).to.equal(true);
|
||||
expect(error.toString()).to.contain("invalid");
|
||||
|
||||
done();
|
||||
});
|
||||
done();
|
||||
});
|
||||
template.render({ name: "John" }, out);
|
||||
};
|
||||
|
||||
@ -289,15 +289,13 @@ describe("AsyncStream", function() {
|
||||
it("should catch error in promise catch if `error` listener only set inside mixin", function(done) {
|
||||
const out = new AsyncStream();
|
||||
|
||||
out
|
||||
.catch(err => {
|
||||
expect(err).to.be.an("error");
|
||||
expect(out.getOutput()).to.equal("1");
|
||||
done();
|
||||
})
|
||||
.then(() => {
|
||||
throw new Error("Should not get here!");
|
||||
});
|
||||
out.catch(err => {
|
||||
expect(err).to.be.an("error");
|
||||
expect(out.getOutput()).to.equal("1");
|
||||
done();
|
||||
}).then(() => {
|
||||
throw new Error("Should not get here!");
|
||||
});
|
||||
|
||||
out.write("1");
|
||||
out.error(new Error("test"));
|
||||
|
||||
@ -62,8 +62,7 @@ describe("AsyncVDOMBuilder", function() {
|
||||
it("promise", function(done) {
|
||||
const out = new AsyncVDOMBuilder();
|
||||
out.element("div", {}, 0);
|
||||
out
|
||||
.end()
|
||||
out.end()
|
||||
.then(result => {
|
||||
expect(getChildNodes(result.getOutput()).length).to.equal(1);
|
||||
done();
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user