-
{{#each tasks}}
{{> task}}
{{/each}}
Rate Limiting
By default, there are rules added to the [`DDPRateLimiter`](./DDPRateLimiter.md) that rate limit logins, new user registration and password reset calls to a limit of 5 requests per 10 seconds per session. These are a basic solution to dictionary attacks where a malicious user attempts to guess the passwords of legitimate users by attempting all possible passwords. These rate limiting rules can be removed by calling `Accounts.removeDefaultRateLimit()`. Please see the [`DDPRateLimiter`](./DDPRateLimiter.md) docs for more information.Enable 2FA for this package
You can add 2FA to your login flow by using the package [accounts-2fa](../packages/accounts-2fa.md). You can find an example showing how this would look like [here](../packages/accounts-2fa.md#working-with-accounts-password). --- --- url: /packages/accounts-2fa.md --- # accounts-2fa This package allows you to provide a way for your users to enable 2FA on their accounts, using an authenticator app such as Google Authenticator, or 1Password. When the user is logged in on your app, they will be able to generate a new QR code and read this code on the app they prefer. After that, they'll start receiving their codes. Then, they can finish enabling 2FA on your app, and every time they try to log in to your app, you can redirect them to a place where they can provide a code they received from the authenticator. To provide codes that are exactly compatible with all other Authenticator apps and services that implements TOTP, this package uses [node-2fa](https://www.npmjs.com/package/node-2fa) which works on top of [notp](https://github.com/guyht/notp), **that** implements TOTP ([RFC 6238](https://www.ietf.org/rfc/rfc6238.txt)) (the Authenticator standard), which is based on HOTP ([RFC 4226](https://www.ietf.org/rfc/rfc4226.txt)). > This package is meant to be used with [`accounts-password`](../api/accounts.md#passwords) or [`accounts-passwordless`](./accounts-passwordless.md), so if you don't have either of those in your project, you'll need to add one of them. In the future, we want to enable the use of this package with other login methods, our oauth methods (Google, GitHub, etc...). ## 2FA Activation Flow {#activating-2fa} The first step, in order to enable 2FA, is to generate a QR code so that the user can scan it in an authenticator app and start receiving codes.Loading...
; if (error) returnError: {error.message}
; return (-
{data.users.map(user => (
- {user.username} ))}
```
If you'd prefer not to move your files, you can use the file names
themselves as the URL prefix:
```js
Meteor.AppCache.config({
onlineOnly: [
'/bigimage.jpg',
'/largedata.json'
]
});
```
though keep in mind that since the exclusion is by prefix (this is a
limitation of the application cache manifest), excluding
`/largedata.json` will also exclude such URLs as
`/largedata.json.orig` and `/largedata.json/file1`.
For more information about how Meteor interacts with the application
cache, see the
[AppCache page](https://github.com/meteor/meteor/wiki/AppCache)
in the Meteor wiki.
---
---
url: /tutorials/security/security.md
---
# Application Security for Production
After reading this tutorial, you'll know:
1. The security surface area of a Meteor app.
2. How to secure Meteor Methods, publications, and source code.
3. Where to store secret keys in development and production.
4. How to follow a security checklist when auditing your app.
5. How App Protection works in Galaxy Hosting.
[[toc]]
## Introduction
Securing a web application is all about understanding security domains and understanding the attack surface between these domains. In a Meteor app, things are pretty simple:
1. Code that runs on the server can be trusted.
2. Everything else: code that runs on the client, data sent through Method and publication arguments, etc, can't be trusted.
In practice, this means that you should do most of your security and validation on the boundary between these two domains. In simple terms:
1. Validate and check all inputs that come from the client.
2. Don't leak any secret information to the client.
### Concept: Attack surface
Since Meteor apps are often written in a style that puts client and server code together, it's extra important to be aware what is running on the client, what is running on the server, and what the boundaries are. Here's a complete list of places security checks need to be done in a Meteor app:
1. **Methods**: Any data that comes in through Method arguments needs to be validated, and Methods should not return data the user shouldn't have access to.
2. **Publications**: Any data that comes in through publication arguments needs to be validated, and publications should not return data the user shouldn't have access to.
3. **Served files**: You should make sure none of the source code or configuration files served to the client have secret data.
Each of these points will have their own section below.
#### Avoid allow/deny
In this guide, we're going to take a strong position that using [allow](/api/collections.html#Mongo-Collection-allow) or [deny](/api/collections.html#Mongo-Collection-deny) to run MongoDB queries directly from the client is not a good idea. The main reason is that it is hard to follow the principles outlined above. It's extremely difficult to validate the complete space of possible MongoDB operators, which could potentially grow over time with new versions of MongoDB.
There have been several articles about the potential pitfalls of accepting MongoDB update operators from the client, in particular the [Allow & Deny Security Challenge](https://web.archive.org/web/20220705130732/https://www.discovermeteor.com/blog/allow-deny-security-challenge/) and its [results](https://web.archive.org/web/20220819163744/https://www.discovermeteor.com/blog/allow-deny-challenge-results/), both on the Discover Meteor blog.
Given the points above, we recommend that all Meteor apps should use Methods to accept data input from the client, and restrict the arguments accepted by each Method as tightly as possible.
Here's a code snippet to add to your server code which disables client-side updates on a collection. This will make sure no other part of your app can use `allow` with the collection `Lists`:
```js
// Deny all client-side updates on the Lists collection
Lists.deny({
insert() { return true; },
update() { return true; },
remove() { return true; },
});
```
## Methods
Methods are the way your Meteor server accepts inputs and data from the outside world, so it's natural that they are the most important topic for security. If you don't properly secure your Methods, users can end up modifying your database in unexpected ways - editing other people's documents, deleting data, or messing up your database schema causing the app to crash.
### Validate all arguments
It's much easier to write clean code if you can assume your inputs are correct, so it's valuable to validate all Method arguments before running any actual business logic. You don't want someone to pass a data type you aren't expecting and cause unexpected behavior.
Consider that if you are writing unit tests for your Methods, you would need to test all possible kinds of input to the Method; validating the arguments restricts the space of inputs you need to unit test, reducing the amount of code you need to write overall. It also has the extra bonus of being self-documenting; someone else can come along and read the code to find out what kinds of parameters a Method is looking for.
Just as an example, here's a situation where not checking arguments can be disastrous:
```js
Meteor.methods({
removeWidget(id) {
if (!this.userId) {
throw new Meteor.Error('removeWidget.unauthorized');
}
Widgets.remove(id);
}
});
```
If someone comes along and passes a non-ID selector like `{}`, they will end up deleting the entire collection.
### jam:method
To help you write good Methods that exhaustively validate their arguments, you can use a community package for Methods that enforces argument validation. Read more about how to use it in the [documentation for jam:method](/community-packages/jam-method). The rest of the code samples in this article will assume that you are using this package. If you aren't, you can still apply the same principles but the code will look a little different.
### Never pass userId from the client
The `this` context inside every Meteor Method has some useful information about the current connection, and the most useful is [`this.userId`](/api/meteor.html#methods-userId). This property is managed by the DDP login system, and is guaranteed by the framework itself to be secure following widely-used best practices.
Given that the user ID of the current user is available through this context, you should never pass the ID of the current user as an argument to a Method. This would allow any client of your app to pass any user ID they want. Let's look at an example:
```js
// #1: Bad! The client could pass any user ID and set someone else's name
async run({ userId, newName }) {
await Meteor.users.updateAsync(userId, {
$set: { name: newName }
});
}
// #2: Good, the client can only set the name on the currently logged in user
async run({ newName }) {
await Meteor.users.updateAsync(this.userId, {
$set: { name: newName }
});
}
```
The _only_ times you should be passing any user ID as an argument are the following:
1. This is a Method only accessible by admin users, who are allowed to edit other users. See the section about [user roles](/packages/roles) to learn how to define roles and check that a user is in a certain role.
2. This Method doesn't modify the other user, but uses it as a target; for example, it could be a Method for sending a private message, or adding a user as a friend.
### One Method per action
The best way to make your app secure is to understand all of the possible inputs that could come from an untrusted source, and make sure that they are all handled correctly. The easiest way to understand what inputs can come from the client is to restrict them to as small of a space as possible. This means your Methods should all be specific actions, and shouldn't take a multitude of options that change the behavior in significant ways. The end goal is that you can look at each Method in your app and validate or test that it is secure. Here's a secure example Method from the Todos example app:
```js
export const makePrivate = createMethod({
name: 'lists.makePrivate',
schema: new SimpleSchema({
listId: { type: String }
}),
async run({ listId }) {
if (!this.userId) {
throw new Meteor.Error('lists.makePrivate.notLoggedIn',
'Must be logged in to make private lists.');
}
const list = await Lists.findOneAsync(listId);
if (list.isLastPublicList()) {
throw new Meteor.Error('lists.makePrivate.lastPublicList',
'Cannot make the last public list private.');
}
await Lists.updateAsync(listId, {
$set: { userId: this.userId }
});
Lists.userIdDenormalizer.set(listId, this.userId);
}
});
```
You can see that this Method does a _very specific thing_ - it makes a single list private. An alternative would have been to have a Method called `setPrivacy`, which could set the list to private or public, but it turns out that in this particular app the security considerations for the two related operations - `makePrivate` and `makePublic` - are very different. By splitting our operations into different Methods, we make each one much clearer. It's obvious from the above Method definition which arguments we accept, what security checks we perform, and what operations we do on the database.
However, this doesn't mean you can't have any flexibility in your Methods. Let's look at an example:
```js
Meteor.users.methods.setUserData = createMethod({
name: 'Meteor.users.methods.setUserData',
schema: new SimpleSchema({
fullName: { type: String, optional: true },
dateOfBirth: { type: Date, optional: true },
}),
async run(fieldsToSet) {
return (await Meteor.users.updateAsync(this.userId, {
$set: fieldsToSet
}));
}
});
```
The above Method is great because you can have the flexibility of having some optional fields and only passing the ones you want to change. In particular, what makes it possible for this Method is that the security considerations of setting one's full name and date of birth are the same - we don't have to do different security checks for different fields being set. Note that it's very important that the `$set` query on MongoDB is generated on the server - we should never take MongoDB operators as-is from the client, since they are hard to validate and could result in unexpected side effects.
#### Refactoring to reuse security rules
You might run into a situation where many Methods in your app have the same security checks. This can be simplified by factoring out the security into a separate module, wrapping the Method body, or extending the `Mongo.Collection` class to do security inside the `insert`, `update`, and `remove` implementations on the server. However, implementing your client-server communication via specific Methods is still a good idea rather than sending arbitrary `update` operators from the client, since a malicious client can't send an `update` operator that you didn't test for.
### Rate limiting
Like REST endpoints, Meteor Methods can be called from anywhere - a malicious program, script in the browser console, etc. It is easy to fire many Method calls in a very short amount of time. This means it can be easy for an attacker to test lots of different inputs to find one that works. Meteor has built-in rate limiting for password login to stop password brute-forcing, but it's up to you to define rate limits for your other Methods.
In the Todos example app, we use the following code to set a basic rate limit on all Methods:
```js
// Get list of all method names on Lists
const LISTS_METHODS = _.pluck([
insert,
makePublic,
makePrivate,
updateName,
remove,
], 'name');
// Only allow 5 list operations per connection per second
if (Meteor.isServer) {
DDPRateLimiter.addRule({
name(name) {
return _.contains(LISTS_METHODS, name);
},
// Rate limit per connection ID
connectionId() { return true; }
}, 5, 1000);
}
```
This will make every Method only callable 5 times per second per connection. This is a rate limit that shouldn't be noticeable by the user at all, but will prevent a malicious script from totally flooding the server with requests. You will need to tune the limit parameters to match your app's needs.
If you're using `jam:method`, it comes with built-in [rate-limiting](https://github.com/jamauro/method#rate-limiting).
## Publications
Publications are the primary way a Meteor server can make data available to a client. While with Methods the primary concern was making sure users can't modify the database in unexpected ways, with publications the main issue is filtering the data being returned so that a malicious user can't get access to data they aren't supposed to see.
### You can't do security at the rendering layer
In a server-side-rendered framework like Ruby on Rails, it's sufficient to not display sensitive data in the returned HTML response. In Meteor, since the rendering is done on the client, an `if` statement in your HTML template is not secure; you need to do security at the data level to make sure that data is never sent in the first place.
### Rules about Methods still apply
All of the points above about Methods apply to publications as well:
1. Validate all arguments using `check` or npm `simpl-schema`.
1. Never pass the current user ID as an argument.
1. Don't take generic arguments; make sure you know exactly what your publication is getting from the client.
1. Use rate limiting to stop people from spamming you with subscriptions.
### Always restrict fields
[`Mongo.Collection#find` has an option called `projection`](/api/collections.html#Mongo-Collection-find) which lets you filter the fields on the fetched documents. You should always use this in publications to make sure you don't accidentally publish secret fields.
For example, you could write a publication, then later add a secret field to the published collection. Now, the publication would be sending that secret to the client. If you filter the fields on every publication when you first write it, then adding another field won't automatically publish it.
```js
// #1: Bad! If we add a secret field to Lists later, the client
// will see it
Meteor.publish('lists.public', function () {
return Lists.find({userId: {$exists: false}});
});
// #2: Good, if we add a secret field to Lists later, the client
// will only publish it if we add it to the list of fields
Meteor.publish('lists.public', function () {
return Lists.find({userId: {$exists: false}}, {
projection: {
name: 1,
incompleteCount: 1,
userId: 1
}
});
});
```
If you find yourself repeating the fields often, it makes sense to factor out a dictionary of public fields that you can always filter by, like so:
```js
// In the file where Lists is defined
Lists.publicFields = {
name: 1,
incompleteCount: 1,
userId: 1
};
```
Now your code becomes a bit simpler:
```js
Meteor.publish('lists.public', function () {
return Lists.find({userId: {$exists: false}}, {
projection: Lists.publicFields
});
});
```
### Publications and userId
The data returned from publications will often be dependent on the currently logged in user, and perhaps some properties about that user - whether they are an admin, whether they own a certain document, etc.
Publications are not reactive, and they only re-run when the currently logged in `userId` changes, which can be accessed through `this.userId`. Because of this, it's easy to accidentally write a publication that is secure when it first runs, but doesn't respond to changes in the app environment. Let's look at an example:
```js
// #1: Bad! If the owner of the list changes, the old owner will still see it
Meteor.publish('list', async function (listId) {
check(listId, String);
const list = await Lists.findOneAsync(listId);
if (list.userId !== this.userId) {
throw new Meteor.Error('list.unauthorized',
'This list doesn\'t belong to you.');
}
return Lists.find(listId, {
projection: {
name: 1,
incompleteCount: 1,
userId: 1
}
});
});
// #2: Good! When the owner of the list changes, the old owner won't see it anymore
Meteor.publish('list', function (listId) {
check(listId, String);
return Lists.find({
_id: listId,
userId: this.userId
}, {
projection: {
name: 1,
incompleteCount: 1,
userId: 1
}
});
});
```
In the first example, if the `userId` property on the selected list changes, the query in the publication will still return the data, since the security check in the beginning will not re-run. In the second example, we have fixed this by putting the security check in the returned query itself.
Unfortunately, not all publications are as simple to secure as the example above. For more tips on how to use `reywood:publish-composite` to handle reactive changes in publications, see the [data loading article](/tutorials/data-loading/data-loading#complex-auth).
### Passing options
For certain applications, for example pagination, you'll want to pass options into the publication to control things like how many documents should be sent to the client. There are some extra considerations to keep in mind for this particular case.
1. **Passing a limit**: In the case where you are passing the `limit` option of the query from the client, make sure to set a maximum limit. Otherwise, a malicious client could request too many documents at once, which could raise performance issues.
2. **Passing in a filter**: If you want to pass fields to filter on because you don't want all of the data, for example in the case of a search query, make sure to use MongoDB `$and` to intersect the filter coming from the client with the documents that client should be allowed to see. Also, you should whitelist the keys that the client can use to filter - if the client can filter on secret data, it can run a search to find out what that data is.
3. **Passing in fields**: If you want the client to be able to decide which fields of the collection should be fetched, make sure to intersect that with the fields that client is allowed to see, so that you don't accidentally send secret data to the client.
In summary, you should make sure that any options passed from the client to a publication can only restrict the data being requested, rather than extending it.
## Served files
Publications are not the only place the client gets data from the server. The set of source code files and static assets that are served by your application server could also potentially contain sensitive data:
1. Business logic an attacker could analyze to find weak points.
1. Secret algorithms that a competitor could steal.
1. Secret API keys.
### Secret server code
While the client-side code of your application is necessarily accessible by the browser, every application will have some secret code on the server that you don't want to share with the world.
Secret business logic in your app should be located in code that is only loaded on the server. This means it is in a `server/` directory of your app, in a package that is only included on the server, or in a file inside a package that was loaded only on the server.
If you have a Meteor Method in your app that has secret business logic, you might want to split the Method into two functions - the optimistic UI part that will run on the client, and the secret part that runs on the server. Most of the time, putting the entire Method on the server doesn't result in the best user experience. Let's look at an example, where you have a secret algorithm for calculating someone's MMR (ranking) in a game:
```js
// In a server-only file, for example /imports/server/mmr.js
export const MMR = {
updateWithSecretAlgorithm(userId) {
// your secret code here
}
}
```
```js
// In a file loaded on client and server
Meteor.users.methods.updateMMR = new createMethod({
name: 'Meteor.users.methods.updateMMR',
validate: null,
run() {
if (this.isSimulation) {
// Simulation code for the client (optional)
} else {
const { MMR } = require('/imports/server/mmr.js');
MMR.updateWithSecretAlgorithm(this.userId);
}
}
});
```
::: warning
Note that while the Method is defined on the client, the actual secret logic is only accessible from the server and the code will **not** be included in the client bundle. Keep in mind that code inside `if (Meteor.isServer)` and `if (!this.isSimulation)` blocks is still sent to the client, it is just not executed. So don't put any secret code in there.
:::
Secret API keys should never be stored in your source code at all, the next section will talk about how to handle them.
## Securing API keys
Every app will have some secret API keys or passwords:
1. Your database password.
1. API keys for external APIs.
These should never be stored as part of your app's source code in version control, because developers might copy code around to unexpected places and forget that it contains secret keys. You can keep your keys separately in [Dropbox](https://www.dropbox.com/), [LastPass](https://lastpass.com), or another service, and then reference them when you need to deploy the app.
You can pass settings to your app through a _settings file_ or an _environment variable_. Most of your app settings should be in JSON files that you pass in when starting your app. You can start your app with a settings file by passing the `--settings` flag:
```sh
# Pass development settings when running your app locally
meteor --settings development.json
# Pass production settings when deploying your app to Galaxy
meteor deploy myapp.com --settings production.json
```
Here's what a settings file with some API keys might look like:
```js
{
"facebook": {
"appId": "12345",
"secret": "1234567"
}
}
```
In your app's JavaScript code, these settings can be accessed from the variable `Meteor.settings`.
[Read more about managing keys and settings in the Deployment article.](/tutorials/deployment/deployment)
### Settings on the client
In most normal situations, API keys from your settings file will only be used by the server, and by default the data passed in through `--settings` is only available on the server. However, if you put data under a special key called `public`, it will be available on the client. You might want to do this if, for example, you need to make an API call from the client and are OK with users knowing that key. Public settings will be available on the client under `Meteor.settings.public`.
### Never store valuable information in public property in settings file
It's ok if you want to make some properties of your settings file accessible to the client but never put any valuable information inside the `public` property. Either explicity store it under `private` property or in its own `property`. Any property that's not under `public` is treated as private by default in Meteor.
```javascript
{
"public": {"publicKey": "xxxxx"},
"private": {"privateKey": "xxxxx"}
}
```
or
```javascript
{
"public": {"publicKey": "xxxxx"},
"privateKey": "xxxxx"
}
```
#### Example: API keys for OAuth
For the `accounts-facebook` package to pick up these keys, you need to add them to the service configuration collection in the database. Here's how you do that:
First, add the `service-configuration` package:
```sh
meteor add service-configuration
```
Then, upsert into the `ServiceConfiguration` collection using private settings:
```js
ServiceConfiguration.configurations.upsert({
service: "facebook"
}, {
$set: {
appId: Meteor.settings.private.facebook.appId,
loginStyle: "popup",
secret: Meteor.settings.private.facebook.secret
}
});
```
Now, `accounts-facebook` will be able to find that API key and Facebook login will work properly.
## SSL
This is a very short section, but it deserves its own place in the table of contents.
**Every production Meteor app that handles user data should run with SSL.**
Yes, Meteor does hash your password or login token on the client before sending it over the wire, but that only prevents an attacker from figuring out your password - it doesn't prevent them from logging in as you, since they could send the hashed password to the server to log in! No matter how you slice it, logging in requires the client to send sensitive data to the server, and the only way to secure that transfer is by using SSL. Note that the same issue is present when using cookies for authentication in a normal HTTP web application, so any app that needs to reliably identify users should be running on SSL.
#### Setting up SSL
* On [Galaxy](/tutorials/deployment/deployment#galaxy-cloud-recommended), configuration of SSL is automatic. [See the help article about SSL on Galaxy](https://help.galaxycloud.app/en/article/encryption-pt8wbl/).
* If you are running on your own [infrastructure](/tutorials/deployment/deployment#custom-deployment), there are a few options for setting up SSL, mostly through configuring a proxy web server. See the articles: [Josh Owens on SSL and Meteor](http://joshowens.me/ssl-and-meteor-js/), [SSL on Meteorpedia](http://www.meteorpedia.com/read/SSL), and [Digital Ocean tutorial with an Nginx config](https://www.digitalocean.com/community/tutorials/how-to-deploy-a-meteor-js-application-on-ubuntu-14-04-with-nginx).
#### Forcing SSL
Generally speaking, all production HTTP requests should go over HTTPS, and all WebSocket data should be sent over WSS.
It's best to handle the redirection from HTTP to HTTPS on the platform which handles the SSL certificates and termination.
* On [Galaxy](/tutorials/deployment/deployment#galaxy-cloud-recommended), enable the "Force HTTPS" setting on a specific domain in the "Domains & Encryption" section of the application's "Settings" tab.
* Other deployments *may* have control panel options or may need to be manually configured on the proxy server (e.g. HAProxy, nginx, etc.). The articles linked above provide some assistance on this.
In the event that a platform does not offer the ability to configure this, the `force-ssl` package can be added to the project and Meteor will attempt to intelligently redirect based on the presence of the `x-forwarded-for` header.
## HTTP Headers
HTTP headers can be used to improve the security of apps, although these are not a silver bullet, they will assist users in mitigating more common attacks.
### Recommended: Helmet
Although there are many great open source solutions for setting HTTP headers, Meteor recommends [Helmet](https://helmetjs.github.io/). Helmet is a collection of 12 smaller middleware functions that set HTTP headers.
First, install helmet.
```js
meteor npm install helmet --save
```
By default, Helmet can be used to set various HTTP headers (see link above). These are a good starting point for mitigating common attacks. To use the default headers, users should use the following code anywhere in their server side meteor startup code.
> Note: Meteor has not extensively tested each header for compatibility with Meteor. Only headers listed below have been tested.
```js
// With other import statements
import helmet from "helmet";
// Within server side Meter.startup()
WebApp.handlers.use(helmet())
```
At a minimum, Meteor recommends users to set the following headers. Note that code examples shown below are specific to Helmet.
### Content Security Policy
> Note: Content Security Policy is not configured using Helmet's default header configuration.
From MDN, Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.
It is recommended that users use CSP to protect their apps from access by third parties. CSP assists to control how resources are loaded into your application.
By default, Meteor recommends unsafe inline scripts and styles are allowed, since many apps typically use them for analytics, etc. Unsafe eval is disallowed, and the only allowable content source is same origin or data, except for connect which allows anything (since meteor apps make websocket connections to a lot of different origins). Browsers will also be told not to sniff content types away from declared content types.
```js
// With other import statements
import helmet from "helmet";
// Within server side Meter.startup()
WebApp.handlers.use(
helmet.contentSecurityPolicy({
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'", "'unsafe-inline'"],
connectSrc: ["*"],
imgSrc: ["'self'"],
styleSrc: ["'self'", "'unsafe-inline'"],
}
})
);
```
Helmet supports a large number of directives, users should further customise their CSP based on their needs. For more detail please read the following guide: [Content Security Policy](https://helmetjs.github.io/docs/csp/). CSP can be complex, so in addition there are some excellent tools out there to help, including [Google's CSP Evaluator](https://csp-evaluator.withgoogle.com/), [Report-URI's CSP Builder](https://report-uri.com/home/generate), [CSP documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) from Mozilla and [CSPValidator](https://cspvalidator.org/).
The following example presents a potential CSP and other Security Headers used in a Production Meteor Application.
This configuration may require customization, depending on your setup and use-cases.
```javascript
/* global __meteor_runtime_config__ */
import { Meteor } from 'meteor/meteor'
import { WebApp } from 'meteor/webapp'
import { Autoupdate } from 'meteor/autoupdate'
import { check } from 'meteor/check'
import crypto from 'crypto'
import helmet from 'helmet'
const self = '\'self\''
const data = 'data:'
const unsafeEval = '\'unsafe-eval\''
const unsafeInline = '\'unsafe-inline\''
const allowedOrigins = Meteor.settings.allowedOrigins
// create the default connect source for our current domain in
// a multi-protocol compatible way (http/ws or https/wss)
const url = Meteor.absoluteUrl()
const domain = url.replace(/http(s)*:\/\//, '').replace(/\/$/, '')
const s = url.match(/(?!=http)s(?=:\/\/)/) ? 's' : ''
const usesHttps = s.length > 0
const connectSrc = [
self,
`http${s}://${domain}`,
`ws${s}://${domain}`
]
// Prepare runtime config for generating the sha256 hash
// It is important, that the hash meets exactly the hash of the
// script in the client bundle.
// Otherwise the app would not be able to start, since the runtimeConfigScript
// is rejected __meteor_runtime_config__ is not available, causing
// a cascade of follow-up errors.
const runtimeConfig = Object.assign(__meteor_runtime_config__, Autoupdate, {
// the following lines may depend on, whether you called Accounts.config
// and whether your Meteor app is a "newer" version
accountsConfigCalled: true,
isModern: true
})
// add client versions to __meteor_runtime_config__
Object.keys(WebApp.clientPrograms).forEach(arch => {
__meteor_runtime_config__.versions[arch] = {
version: Autoupdate.autoupdateVersion || WebApp.clientPrograms[arch].version(),
versionRefreshable: Autoupdate.autoupdateVersion || WebApp.clientPrograms[arch].versionRefreshable(),
versionNonRefreshable: Autoupdate.autoupdateVersion || WebApp.clientPrograms[arch].versionNonRefreshable(),
// comment the following line if you use Meteor < 2.0
versionReplaceable: Autoupdate.autoupdateVersion || WebApp.clientPrograms[arch].versionReplaceable()
}
})
const runtimeConfigScript = `__meteor_runtime_config__ = JSON.parse(decodeURIComponent("${encodeURIComponent(JSON.stringify(runtimeConfig))}"))`
const runtimeConfigHash = crypto.createHash('sha256').update(runtimeConfigScript).digest('base64')
const helpmentOptions = {
contentSecurityPolicy: {
blockAllMixedContent: true,
directives: {
defaultSrc: [self],
scriptSrc: [
self,
// Remove / comment out unsafeEval if you do not use dynamic imports
// to tighten security. However, if you use dynamic imports this line
// must be kept in order to make them work.
unsafeEval,
`'sha256-${runtimeConfigHash}'`
],
childSrc: [self],
// If you have external apps, that should be allowed as sources for
// connections or images, your should add them here
// Call helmetOptions() without args if you have no external sources
// Note, that this is just an example and you may configure this to your needs
connectSrc: connectSrc.concat(allowedOrigins),
fontSrc: [self, data],
formAction: [self],
frameAncestors: [self],
frameSrc: ['*'],
// This is an example to show, that we can define to show images only
// from our self, browser data/blob and a defined set of hosts.
// Configure to your needs.
imgSrc: [self, data, 'blob:'].concat(allowedOrigins),
manifestSrc: [self],
mediaSrc: [self],
objectSrc: [self],
// these are just examples, configure to your needs, see
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox
sandbox: [
// allow-downloads-without-user-activation // experimental
'allow-forms',
'allow-modals',
// 'allow-orientation-lock',
// 'allow-pointer-lock',
// 'allow-popups',
// 'allow-popups-to-escape-sandbox',
// 'allow-presentation',
'allow-same-origin',
'allow-scripts',
// 'allow-storage-access-by-user-activation ', // experimental
// 'allow-top-navigation',
// 'allow-top-navigation-by-user-activation'
],
styleSrc: [self, unsafeInline],
workerSrc: [self, 'blob:']
}
},
// see the helmet documentation to get a better understanding of
// the following configurations and settings
strictTransportSecurity: {
maxAge: 15552000,
includeSubDomains: true,
preload: false
},
referrerPolicy: {
policy: 'no-referrer'
},
expectCt: {
enforce: true,
maxAge: 604800
},
frameguard: {
action: 'sameorigin'
},
dnsPrefetchControl: {
allow: false
},
permittedCrossDomainPolicies: {
permittedPolicies: 'none'
}
}
// We assume, that we are working on a localhost when there is no https
// connection available.
// Run your project with --production flag to simulate script-src hashing
if (!usesHttps && Meteor.isDevelopment) {
delete helpmentOptions.contentSecurityPolicy.blockAllMixedContent;
helpmentOptions.contentSecurityPolicy.directives.scriptSrc = [
self,
unsafeEval,
unsafeInline,
];
}
// finally pass the options to helmet to make them apply
helmet(helpmentOptions)
```
### X-Frame-Options
> Note: The X-Frame Options header is configured using Helmet's default header configuration.
From MDN, the X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a ``, `
## Contributing to this documentation
We welcome contributions to the documentation!
Since documentation is always evolving, your help is really valuable to ensure content is accurate and up-to-date.
### How to Contribute
#### Identify elements that need improvement
Are you new here? Please check our [documentation issues](https://github.com/meteor/meteor/issues?q=is%3Aissue%20state%3Aopen%20label%3AProject%3ADocs).
If in doubt about the best way to implement something, please create additional conversation on the issue.
Issues are not assigned, you don’t need to wait for approval before contributing. Jump right in and open a PR — this increases your chances of getting your work merged, since issues can be claimed fast.
#### Do the changes and share them
Documentation live in the `v3-docs/docs` directory of the [Meteor GitHub repository](https://github.com/meteor/meteor/tree/devel/v3-docs/docs)
For small changes, such as fixing typos or formatting, you can simply click the "Edit this page on GitHub" button in the footer to edit the file and submit a PR.
For larger changes, you need to fork meteor repo and start your work from the `devel` branch.
You must test your contribution locally before submitting a pull request. To do so, here are the steps:
1. `cd v3-docs/docs && npm run docs:dev` will run the docs locally at [http://localhost:5173/](http://localhost:5173/)
2. Make your changes and verify them in the browser.
3. run `npm run docs:build` to ensure the build works correctly.
4. Push your work and submit a documented pull request to the `devel` branch.
If you add a new page to the documentation, please make sure the configuration creates a link to access it (see [.vitepress/config.mts](https://github.com/meteor/meteor/blob/devel/v3-docs/docs/.vitepress/config.mts)).
---
---
url: /CONTRIBUTING.md
---
---
---
url: /api/index.md
---
{{#if isUserLoggedIn}}
{{> form }}
...
```
:::
As you can see, if the user is logged in, we render the whole app (`isUserLoggedIn`). Otherwise, we render the Login template. Let’s now create our helper `isUserLoggedIn`:
::: code-group
```js [imports/ui/App.js]
...
const getUser = () => Meteor.user();
const isUserLoggedInChecker = () => Boolean(getUser());
...
Template.mainContainer.helpers({
...,
isUserLoggedIn() {
return isUserLoggedInChecker();
},
});
...
```
:::
### 7.5: Login Form style
Ok, let's style the login form now:
::: code-group
```css [client/main.css]
.login-form {
display: flex;
flex-direction: column;
height: 100%;
justify-content: center;
align-items: center;
}
.login-form > div {
margin: 8px;
}
.login-form > div > label {
font-weight: bold;
}
.login-form > div > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
margin-top: 4px;
}
.login-form > div > input:focus {
outline: 0;
}
.login-form > div > button {
background-color: #62807e;
}
```
:::
Now your login form should be centralized and beautiful.
### 7.6: Server startup
Every task should have an owner from now on. So go to your database, as you learn before, and remove all the tasks from there:
`db.tasks.remove({});`
Change your `server/main.js` to add the seed tasks using your `meteorite` user as owner.
Make sure you restart the server after this change so `Meteor.startup` block will run again. This is probably going to happen automatically anyway as you are going to make changes in the server side code.
::: code-group
```js [server/main.js]
...
const user = await Accounts.findUserByUsername(SEED_USERNAME);
if ((await TasksCollection.find().countAsync()) === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach((taskName) => {
Meteor.callAsync("tasks.insert", {
text: taskName,
createdAt: new Date(),
userId: user._id
});
});
}
...
```
:::
See that we are using a new field called `userId` with our user `_id` field, we are also setting `createdAt` field.
### 7.7: Task owner
First, let's change our publication to publish the tasks only for the currently logged user. This is important for security, as you send only data that belongs to that user.
::: code-group
```js [/imports/api/TasksPublications.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.publish("tasks", function () {
let result = this.ready();
const userId = this.userId;
if (userId) {
result = TasksCollection.find({ userId });
}
return result;
});
```
:::
Now let's check if we have a `user` before trying to fetch any data:
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
tasks() {
let result = [];
if (isUserLoggedInChecker()) {
const instance = Template.instance();
const hideCompleted = instance.state.get(HIDE_COMPLETED_STRING);
const hideCompletedFilter = { isChecked: { $ne: true } };
result = TasksCollection.find(hideCompleted ? hideCompletedFilter : {}, {
sort: { createdAt: -1, _id: -1 },
}).fetch();
}
return result;
},
hideCompleted() {
return Template.instance().state.get(HIDE_COMPLETED_STRING);
},
incompleteCount() {
result = '';
if (isUserLoggedInChecker()) {
const incompleteTasksCount = TasksCollection.find({ isChecked: { $ne: true } }).count();
result = incompleteTasksCount ? `(${incompleteTasksCount})` : '';
}
return result;
},
isUserLoggedIn() {
return isUserLoggedInChecker();
},
});
...
```
:::
Also, update the `tasks.insert` method to include the field `userId` when creating a new task:
::: code-group
```js [imports/api/TasksMethods.js]
...
Meteor.methods({
"tasks.insert"(doc) {
const insertDoc = { ...doc };
if (!('userId' in insertDoc)) {
insertDoc.userId = this.userId;
}
return TasksCollection.insertAsync(insertDoc);
},
...
```
:::
### 7.8: Log out
We can also organize our tasks by showing the owner’s username below our app bar. Let’s add a new `div` where the user can click and log out from the app:
::: code-group
```html [imports/ui/App.html]
...
{{#if isUserLoggedIn}}
In the next step, we are going to learn how to deploy your app!
---
---
url: /tutorials/blaze/6.filter-tasks.md
---
## 6: Filter tasks
In this step, you will filter your tasks by status and show the number of pending tasks.
### 6.1: ReactiveDict
First, you will add a button to show or hide the completed tasks from the list.
To keep the state, we will use the `ReactiveDict`, a reactive dictionary which enables us to store an arbitrary set of key-value pairs. Use it to manage the internal state in your components, i.e. the currently selected item in a list. To know more about how `ReactiveDict` works, you can click on this [link](/api/ReactiveDict), and there you will find everything you need to know and everything you can do with it.
We need to install the `reactive-dict` package in our app. Simply run the command below on your app root directory:
```shell
meteor add reactive-dict
```
Next, we need to set up a new `ReactiveDict` and attach it to the `mainContainer` template instance (as this is where we’ll store the button’s state) when it is first created. The best place to create our variables is inside the callback onCreated of the template that we want to persist our data. This callback is called as soon as the template renders on the screen:
::: code-group
```js [imports/ui/App.js]
import { Template } from 'meteor/templating';
import { ReactiveDict } from 'meteor/reactive-dict';
import { TasksCollection } from "../api/TasksCollection";
import '/imports/api/TasksMethods.js'; // this import in this client UI allows for optimistic execution
import './App.html';
import './Task';
Template.mainContainer.onCreated(function mainContainerOnCreated() {
this.state = new ReactiveDict();
Meteor.subscribe('tasks');
});
...
```
:::
Then, we need an event handler to update the `ReactiveDict` variable when the button is clicked. An event handler takes two arguments, the second of which is the same template instance in the onCreated callback. Also, create a new constant called `HIDE_COMPLETED_STRING` below the imports, that will be used throughout the code as the name of the variable we are persisting:
::: code-group
```js [imports/ui/App.js]
...
const HIDE_COMPLETED_STRING = "hideCompleted";
...
Template.mainContainer.events({
"click #hide-completed-button"(event, instance) {
const currentHideCompleted = instance.state.get(HIDE_COMPLETED_STRING);
instance.state.set(HIDE_COMPLETED_STRING, !currentHideCompleted);
}
});
...
```
:::
The button in the UI to toggle our state will look something like this:
::: code-group
```html [imports/ui/App.html]
...
You can also see all the messages that Meteor is sending and receiving from the server, this is useful for you to learn more about how Meteor works.
Install it in your Google Chrome browser using this [link](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf).
### 6.5: Pending tasks
Update the App component in order to show the number of pending tasks in the app bar.
You should avoid adding zero to your app bar when there are no pending tasks.
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
...,
incompleteCount() {
const incompleteTasksCount = TasksCollection.find({ isChecked: { $ne: true } }).count();
return incompleteTasksCount ? `(${incompleteTasksCount})` : '';
},
});
...
```
:::
::: code-group
```html [imports/ui/App.html]
...
...
```
:::
Your app should look like this:
In the next step we are going to include user access in your app.
---
---
url: /tutorials/blaze/5.styles.md
---
## 5: Styles
### 5.1: CSS
Our user interface up until this point has looked quite ugly. Let's add some basic styling which will serve as the foundation for a more professional looking app.
Replace the content of our `client/main.css` file with the one below, the idea is to have an app bar at the top, and a scrollable content including:
- form to add new tasks;
- list of tasks.
::: code-group
```css [client/main.css]
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
button {
font-weight: bold;
font-size: 1em;
border: none;
color: white;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
padding: 5px;
cursor: pointer;
}
button:focus {
outline: 0;
}
.app {
display: flex;
flex-direction: column;
height: 100vh;
}
.app-header {
flex-grow: 1;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.main {
display: flex;
flex-direction: column;
flex-grow: 1;
overflow: auto;
background: white;
}
.main::-webkit-scrollbar {
width: 0;
height: 0;
background: inherit;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
}
.app-bar {
display: flex;
justify-content: space-between;
}
.app-bar h1 {
font-size: 1.5em;
margin: 0;
display: inline-block;
margin-right: 1em;
}
.task-form {
display: flex;
margin: 16px;
}
.task-form > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
}
.task-form > input:focus {
outline: 0;
}
.task-form > button {
min-width: 100px;
height: 95%;
background-color: #315481;
}
.tasks {
list-style-type: none;
padding-inline-start: 0;
padding-left: 16px;
padding-right: 16px;
margin-block-start: 0;
margin-block-end: 0;
}
.tasks > li {
display: flex;
padding: 16px;
border-bottom: #eee solid 1px;
align-items: center;
}
.tasks > li > label {
flex-grow: 1;
}
.tasks > li > button {
justify-self: flex-end;
background-color: #ff3046;
}
```
:::
> If you want to learn more about this stylesheet check this article about [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/), and also this free [video tutorial](https://flexbox.io/) about it from [Wes Bos](https://twitter.com/wesbos).
>
> Flexbox is an excellent tool to distribute and align elements in your UI.
### 5.2: Applying styles
Now you need to add some elements around your components. You are going to add a `class` to your main div in the `App`, also a `header` element with a few `divs` around your `h1`, and a main `div` around your form and list. Check below how it should be, pay attention to the name of the classes, they need to be the same as in the CSS file:
::: code-group
```html [imports/ui/App.html]
...
...
```
:::
Your app should look like this:
In the next step, we are going to make this task list more interactive, for example, providing a way to filter tasks.
---
---
url: /tutorials/blaze/4.update-and-remove.md
---
## 4: Update and Remove
Up until now, you have only inserted documents into our collection. Let's take a look at how you can update and remove them by interacting with the user interface.
### 4.1: Add Checkbox
First, you need to add a `checkbox` element to your `Task` component.
Next, let’s create a new file for our `task` template in `imports/ui/Task.html`, so we can start to separate the logic in our app.
::: code-group
```html [imports/ui/Task.html]
```
:::
Don’t forget to remove the template named `task` in `imports/ui/App.html`.
You must also add the following import:
::: code-group
```js [imports/ui/App.js]
...
import './Task';
...
```
:::
### 4.2: Toggle Checkbox
Now you can update your task document by toggling its `isChecked` field.
First, create a new method called `tasks.toggleChecked` to update the `isChecked` property.
::: code-group
```js [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
..
"tasks.toggleChecked"({ _id, isChecked }) {
return TasksCollection.updateAsync(_id, {
$set: { isChecked: !isChecked },
});
},
});
```
:::
Create a new file called `Task.js` so we can have our handlers to the `task` template:
::: code-group
```js [imports/ui/Task.js]
import { Template } from 'meteor/templating';
import { TasksCollection } from "../api/TasksCollection";
import '/imports/api/TasksMethods.js'; // this import in this client UI allows for optimistic execution
import './Task.html';
Template.task.events({
'click .toggle-checked'() {
// Set the checked property to the opposite of its current value
let taskID = this._id;
let checkedValue = Boolean(this.isChecked);
Meteor.callAsync("tasks.toggleChecked", { _id: taskID, isChecked: checkedValue });
},
});
```
:::
Toggling checkboxes should now persist in the DB even if you refresh the web browser.
Your app should look like this:
If your computer is fast enough, it's possible that when it sets up the default tasks a few will have the same date. That will cause them to non-deterministically "jump around" in the UI as you toggle checkboxes and the UI reactively updates. To make it stable, you can add a secondary sort on the `_id` of the task:
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
tasks() {
return TasksCollection.find({}, { sort: { createdAt: -1, _id: -1 } });
},
...
```
:::
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after text `label` in your `Task` component.
::: code-group
```html [imports/ui/Task.html]
...
```
:::
Next you need to have a function to delete the task. For that, let's create a new method called `tasks.delete`:
::: code-group
```js [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
..
"tasks.delete"({ _id }) {
return TasksCollection.removeAsync(_id);
},
});
```
:::
Now add the removal logic in the `Task.js`. It will just be a new event to the `task` template that is activated when the user clicks on a delete button (i.e. any button with the class `delete`):
::: code-group
```javascript [imports/ui/Task.js]
...
Template.task.events({
...,
'click .delete'() {
let taskID = this._id;
Meteor.callAsync("tasks.delete", { _id: taskID });
},
});
```
:::
Your app should look like this:
### 4.4: Getting data in event handlers
In a collection, every inserted document has a unique `_id` field that can refer to that specific document. Inside the event handlers, `this` refers to an individual task object. We can get the `_id` of the current task with `this._id` and any other field available on the client-side. Once we have the `_id`, we can use, update, and remove the relevant task. That’s how our code will update or remove a task.
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/blaze/3.forms-and-events.md
---
## 3: Forms and Events
All apps need to allow the user to perform some sort of interaction with the data that is stored. In our case, the first type of interaction is to insert new tasks. Without it, our To-Do app wouldn't be very helpful.
One of the main ways in which a user can insert or edit data on a website is through forms. In most cases, it is a good idea to use the `
);
};
```
:::
### 3.2: Update the Stylesheet
You also can style it as you wish. For now, we only need some margin at the top so the form doesn't seem off the mark. Add the CSS class `.task-form`, this needs to be the same name in your `class` attribute in the form element. Notice how in Solid you don't use `className` like you would in React.
::: code-group
```css [imports/ui/main.css]
...
.task-form {
margin-top: 1rem;
}
...
```
:::
### 3.3: Add Submit Handler
Now let's create a function to handle the form submit and insert a new task into the database. To do it, we will need to implement a Meteor Method.
Methods are essentially RPC calls to the server that let you perform operations on the server side securely. You can read more about Meteor Methods [here](/tutorials/methods/methods).
To create your methods, you can create a file called `TasksMethods.js`.
::: code-group
```javascript [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
"tasks.insert"(doc) {
return TasksCollection.insertAsync(doc);
},
});
```
:::
Remember to import your method on the `main.js` server file, delete the `insertTask` function, and invoke the new meteor method inside the `forEach` block.
::: code-group
```javascript [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
import "../imports/api/TasksPublications";
import "../imports/api/TasksMethods"; // [!code highlight]
Meteor.startup(async () => {
if ((await TasksCollection.find().countAsync()) === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach((taskName) => {
Meteor.callAsync("tasks.insert", { // [!code highlight]
text: taskName, // [!code highlight]
createdAt: new Date(), // [!code highlight]
});
});
}
});
```
:::
Inside the `forEach` function, we are adding a task to the `tasks` collection by calling `Meteor.callAsync()`. The first argument is the name of the method we want to call, and the second argument is the text of the task.
Also, insert a date `createdAt` in your `task` document so you know when each task was created.
Now we need to import `TasksMethods.js` in a client-side file to enable optimistic UI (e.g., in `imports/ui/main.jsx`):
::: code-group
```jsx [imports/ui/main.jsx]
/* @refresh reload */
import { render } from 'solid-js/web';
import { App } from './App';
import { Meteor } from "meteor/meteor";
import './main.css';
import "/imports/api/TasksMethods"; // [!code highlight] // this import allows for optimistic execution
Meteor.startup(() => {
render(() => 
In the next step, we are going to update your tasks state and provide a way for users to remove tasks.
---
---
url: /tutorials/solid/2.collections.md
---
## 2: Collections
Meteor already sets up MongoDB for you. In order to use our database, we need to create a _collection_, which is where we will store our _documents_, in our case our `tasks`.
> You can read more about collections [here](/api/collections).
In this step we will implement all the necessary code to have a basic collection for our tasks up and running.
### 2.1: Create Tasks Collection
We can create a new collection to store our tasks by creating a new file at `imports/api/TasksCollection.js` which instantiates a new Mongo collection and exports it.
::: code-group
```js [imports/api/TasksCollection.js]
import { Mongo } from "meteor/mongo";
export const TasksCollection = new Mongo.Collection("tasks");
```
:::
Notice that we stored the file in the `imports/api` directory, which is a place to store API-related code, like publications and methods. You can name this folder as you want, this is just a choice.
If there is a `imports/api/links.js` file from the starter project, you can delete that now as we don't need it.
> You can read more about app structure and imports/exports [here](/tutorials/application-structure/).
### 2.2: Initialize Tasks Collection
For our collection to work, you need to import it in the server so it sets some plumbing up.
You can either use `import "/imports/api/TasksCollection"` or `import { TasksCollection } from "/imports/api/TasksCollection"` if you are going to use on the same file, but make sure it is imported.
Now it is easy to check if there is data or not in our collection, otherwise, we can insert some sample data easily as well.
You don't need to keep the old content of `server/main.js`.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = async (taskText) =>
await TasksCollection.insertAsync({ text: taskText });
Meteor.startup(async () => {
if (await TasksCollection.find().countAsync() === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach(insertTask);
}
});
```
:::
So you are importing the `TasksCollection` and adding a few tasks to it iterating over an array of strings and for each string calling a function to insert this string as our `text` field in our `task` document.
### 2.3: Render Tasks Collection
Now comes the fun part, you will render the tasks with Solid. That will be pretty simple.
In your `App.jsx` file, import the `TasksCollection` and use Tracker to subscribe and fetch the tasks reactively:
::: code-group
```jsx [imports/ui/App.jsx]
import { createSignal, For, Show } from "solid-js";
import { Meteor } from "meteor/meteor";
import { Tracker } from "meteor/tracker";
import { TasksCollection } from "../api/TasksCollection";
export const App = () => {
const subscription = Meteor.subscribe("tasks");
const [isReady, setIsReady] = createSignal(subscription.ready());
const [tasks, setTasks] = createSignal([]);
Tracker.autorun(async () => {
setIsReady(subscription.ready());
setTasks(await TasksCollection.find().fetchAsync());
});
return (
Loading ... }
>
);
};
```
:::
But wait! Something is missing. If you run your app now, you'll see that you don't render any tasks.
That's because we need to publish our data to the client.
> For more information on Publications/Subscriptions, please check our [docs](/api/meteor#pubsub).
Meteor doesn't need REST calls. It instead relies on synchronizing the MongoDB on the server with a MiniMongoDB on the client. It does this by first publishing collections on the server and then subscribing to them on the client.
First, create a publication for our tasks:
::: code-group
```javascript [imports/api/TasksPublications.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.publish("tasks", function () {
return TasksCollection.find();
});
```
:::
Now, we need to import this file in our server:
::: code-group
```js [server/main.js]
...
import { TasksCollection } from '/imports/api/TasksCollection';
import "../imports/api/TasksPublications"; // [!code highlight]
const insertTask = taskText => TasksCollection.insertAsync({ text: taskText });
...
```
:::
The only thing left is subscribe to this publication, which we've already added in `App.jsx` using:
::: code-group
```jsx [imports/ui/App.jsx]
...
const subscription = Meteor.subscribe("tasks");
...
```
:::
See how your app should look like now:
{{getUser.username}} 🚪
{{> form }}
...
```
:::
Now, let’s create the `getUser` helper and implement the event that will log out the user when they click on this `div`. Logging out is done by calling the function `Meteor.logout()`:
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.events({
...,
'click .user'() {
Meteor.logout();
},
});
...
Template.mainContainer.helpers({
...,
getUser() {
return getUser();
},
});
...
```
:::
Remember to style your username as well.
::: code-group
```css [client/main.css]
.user {
display: flex;
align-self: flex-end;
margin: 8px 16px 0;
font-weight: bold;
cursor: pointer;
}
```
:::
Phew! You have done quite a lot in this step. Authenticated the user, set the user in the tasks, and provided a way for the user to log out.
Your app should look like this:
In the next step, we are going to learn how to deploy your app!
---
---
url: /tutorials/blaze/6.filter-tasks.md
---
## 6: Filter tasks
In this step, you will filter your tasks by status and show the number of pending tasks.
### 6.1: ReactiveDict
First, you will add a button to show or hide the completed tasks from the list.
To keep the state, we will use the `ReactiveDict`, a reactive dictionary which enables us to store an arbitrary set of key-value pairs. Use it to manage the internal state in your components, i.e. the currently selected item in a list. To know more about how `ReactiveDict` works, you can click on this [link](/api/ReactiveDict), and there you will find everything you need to know and everything you can do with it.
We need to install the `reactive-dict` package in our app. Simply run the command below on your app root directory:
```shell
meteor add reactive-dict
```
Next, we need to set up a new `ReactiveDict` and attach it to the `mainContainer` template instance (as this is where we’ll store the button’s state) when it is first created. The best place to create our variables is inside the callback onCreated of the template that we want to persist our data. This callback is called as soon as the template renders on the screen:
::: code-group
```js [imports/ui/App.js]
import { Template } from 'meteor/templating';
import { ReactiveDict } from 'meteor/reactive-dict';
import { TasksCollection } from "../api/TasksCollection";
import '/imports/api/TasksMethods.js'; // this import in this client UI allows for optimistic execution
import './App.html';
import './Task';
Template.mainContainer.onCreated(function mainContainerOnCreated() {
this.state = new ReactiveDict();
Meteor.subscribe('tasks');
});
...
```
:::
Then, we need an event handler to update the `ReactiveDict` variable when the button is clicked. An event handler takes two arguments, the second of which is the same template instance in the onCreated callback. Also, create a new constant called `HIDE_COMPLETED_STRING` below the imports, that will be used throughout the code as the name of the variable we are persisting:
::: code-group
```js [imports/ui/App.js]
...
const HIDE_COMPLETED_STRING = "hideCompleted";
...
Template.mainContainer.events({
"click #hide-completed-button"(event, instance) {
const currentHideCompleted = instance.state.get(HIDE_COMPLETED_STRING);
instance.state.set(HIDE_COMPLETED_STRING, !currentHideCompleted);
}
});
...
```
:::
The button in the UI to toggle our state will look something like this:
::: code-group
```html [imports/ui/App.html]
...
{{> form }}
...
```
:::
You may notice we’re using `if` (a conditional test) for the first time, and it’s pretty straightforward. You can learn more about the conditional test, `if`, [here](http://blazejs.org/api/spacebars.html#If-Unless). We’re also using a helper called `hideCompleted` that we didn’t create yet, but we will shortly.
### 6.2: Button style
You should add some style to your button so it does not look gray and without a good contrast. You can use the styles below as a reference:
::: code-group
```css [client/main.css]
.filter {
display: flex;
justify-content: center;
}
.filter > button {
background-color: #62807e;
}
```
:::
### 6.3: Filter Tasks
Now, we need to update `Template.mainContainer.helpers`. The code below verifies if the variable `hideCompleted` is set to true and if yes, we filter our query to get non completed tasks. We also have a new helper called `hideCompleted` that will help us in the UI where we want to know if we’re filtering or not:
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
tasks() {
const instance = Template.instance();
const hideCompleted = instance.state.get(HIDE_COMPLETED_STRING);
const hideCompletedFilter = { isChecked: { $ne: true } };
return TasksCollection.find(hideCompleted ? hideCompletedFilter : {}, {
sort: { createdAt: -1, _id: -1 },
}).fetch();
},
hideCompleted() {
return Template.instance().state.get(HIDE_COMPLETED_STRING);
},
});
...
```
:::
### 6.4: Meteor Dev Tools Extension
You can install an extension to visualize the data in your Mini Mongo.
[Meteor DevTools Evolved](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf) will help you to debug your app as you can see what data is on Mini Mongo.
-
{{#each tasks}}
{{> task}}
{{/each}}
You can also see all the messages that Meteor is sending and receiving from the server, this is useful for you to learn more about how Meteor works.
Install it in your Google Chrome browser using this [link](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf).
### 6.5: Pending tasks
Update the App component in order to show the number of pending tasks in the app bar.
You should avoid adding zero to your app bar when there are no pending tasks.
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
...,
incompleteCount() {
const incompleteTasksCount = TasksCollection.find({ isChecked: { $ne: true } }).count();
return incompleteTasksCount ? `(${incompleteTasksCount})` : '';
},
});
...
```
:::
::: code-group
```html [imports/ui/App.html]
...
In the next step we are going to include user access in your app.
---
---
url: /tutorials/blaze/5.styles.md
---
## 5: Styles
### 5.1: CSS
Our user interface up until this point has looked quite ugly. Let's add some basic styling which will serve as the foundation for a more professional looking app.
Replace the content of our `client/main.css` file with the one below, the idea is to have an app bar at the top, and a scrollable content including:
- form to add new tasks;
- list of tasks.
::: code-group
```css [client/main.css]
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
button {
font-weight: bold;
font-size: 1em;
border: none;
color: white;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
padding: 5px;
cursor: pointer;
}
button:focus {
outline: 0;
}
.app {
display: flex;
flex-direction: column;
height: 100vh;
}
.app-header {
flex-grow: 1;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.main {
display: flex;
flex-direction: column;
flex-grow: 1;
overflow: auto;
background: white;
}
.main::-webkit-scrollbar {
width: 0;
height: 0;
background: inherit;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
}
.app-bar {
display: flex;
justify-content: space-between;
}
.app-bar h1 {
font-size: 1.5em;
margin: 0;
display: inline-block;
margin-right: 1em;
}
.task-form {
display: flex;
margin: 16px;
}
.task-form > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
}
.task-form > input:focus {
outline: 0;
}
.task-form > button {
min-width: 100px;
height: 95%;
background-color: #315481;
}
.tasks {
list-style-type: none;
padding-inline-start: 0;
padding-left: 16px;
padding-right: 16px;
margin-block-start: 0;
margin-block-end: 0;
}
.tasks > li {
display: flex;
padding: 16px;
border-bottom: #eee solid 1px;
align-items: center;
}
.tasks > li > label {
flex-grow: 1;
}
.tasks > li > button {
justify-self: flex-end;
background-color: #ff3046;
}
```
:::
> If you want to learn more about this stylesheet check this article about [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/), and also this free [video tutorial](https://flexbox.io/) about it from [Wes Bos](https://twitter.com/wesbos).
>
> Flexbox is an excellent tool to distribute and align elements in your UI.
### 5.2: Applying styles
Now you need to add some elements around your components. You are going to add a `class` to your main div in the `App`, also a `header` element with a few `divs` around your `h1`, and a main `div` around your form and list. Check below how it should be, pay attention to the name of the classes, they need to be the same as in the CSS file:
::: code-group
```html [imports/ui/App.html]
...
{{> form }}
-
{{#each tasks}}
{{> task}}
{{/each}}
In the next step, we are going to make this task list more interactive, for example, providing a way to filter tasks.
---
---
url: /tutorials/blaze/4.update-and-remove.md
---
## 4: Update and Remove
Up until now, you have only inserted documents into our collection. Let's take a look at how you can update and remove them by interacting with the user interface.
### 4.1: Add Checkbox
First, you need to add a `checkbox` element to your `Task` component.
Next, let’s create a new file for our `task` template in `imports/ui/Task.html`, so we can start to separate the logic in our app.
::: code-group
```html [imports/ui/Task.html]
If your computer is fast enough, it's possible that when it sets up the default tasks a few will have the same date. That will cause them to non-deterministically "jump around" in the UI as you toggle checkboxes and the UI reactively updates. To make it stable, you can add a secondary sort on the `_id` of the task:
::: code-group
```js [imports/ui/App.js]
...
Template.mainContainer.helpers({
tasks() {
return TasksCollection.find({}, { sort: { createdAt: -1, _id: -1 } });
},
...
```
:::
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after text `label` in your `Task` component.
::: code-group
```html [imports/ui/Task.html]
### 4.4: Getting data in event handlers
In a collection, every inserted document has a unique `_id` field that can refer to that specific document. Inside the event handlers, `this` refers to an individual task object. We can get the `_id` of the current task with `this._id` and any other field available on the client-side. Once we have the `_id`, we can use, update, and remove the relevant task. That’s how our code will update or remove a task.
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/blaze/3.forms-and-events.md
---
## 3: Forms and Events
All apps need to allow the user to perform some sort of interaction with the data that is stored. In our case, the first type of interaction is to insert new tasks. Without it, our To-Do app wouldn't be very helpful.
One of the main ways in which a user can insert or edit data on a website is through forms. In most cases, it is a good idea to use the `
In the next step, we are going to update your tasks state and provide a way for users to remove tasks.
---
---
url: /tutorials/solid/2.collections.md
---
## 2: Collections
Meteor already sets up MongoDB for you. In order to use our database, we need to create a _collection_, which is where we will store our _documents_, in our case our `tasks`.
> You can read more about collections [here](/api/collections).
In this step we will implement all the necessary code to have a basic collection for our tasks up and running.
### 2.1: Create Tasks Collection
We can create a new collection to store our tasks by creating a new file at `imports/api/TasksCollection.js` which instantiates a new Mongo collection and exports it.
::: code-group
```js [imports/api/TasksCollection.js]
import { Mongo } from "meteor/mongo";
export const TasksCollection = new Mongo.Collection("tasks");
```
:::
Notice that we stored the file in the `imports/api` directory, which is a place to store API-related code, like publications and methods. You can name this folder as you want, this is just a choice.
If there is a `imports/api/links.js` file from the starter project, you can delete that now as we don't need it.
> You can read more about app structure and imports/exports [here](/tutorials/application-structure/).
### 2.2: Initialize Tasks Collection
For our collection to work, you need to import it in the server so it sets some plumbing up.
You can either use `import "/imports/api/TasksCollection"` or `import { TasksCollection } from "/imports/api/TasksCollection"` if you are going to use on the same file, but make sure it is imported.
Now it is easy to check if there is data or not in our collection, otherwise, we can insert some sample data easily as well.
You don't need to keep the old content of `server/main.js`.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = async (taskText) =>
await TasksCollection.insertAsync({ text: taskText });
Meteor.startup(async () => {
if (await TasksCollection.find().countAsync() === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach(insertTask);
}
});
```
:::
So you are importing the `TasksCollection` and adding a few tasks to it iterating over an array of strings and for each string calling a function to insert this string as our `text` field in our `task` document.
### 2.3: Render Tasks Collection
Now comes the fun part, you will render the tasks with Solid. That will be pretty simple.
In your `App.jsx` file, import the `TasksCollection` and use Tracker to subscribe and fetch the tasks reactively:
::: code-group
```jsx [imports/ui/App.jsx]
import { createSignal, For, Show } from "solid-js";
import { Meteor } from "meteor/meteor";
import { Tracker } from "meteor/tracker";
import { TasksCollection } from "../api/TasksCollection";
export const App = () => {
const subscription = Meteor.subscribe("tasks");
const [isReady, setIsReady] = createSignal(subscription.ready());
const [tasks, setTasks] = createSignal([]);
Tracker.autorun(async () => {
setIsReady(subscription.ready());
setTasks(await TasksCollection.find().fetchAsync());
});
return (
Todo List
- {task.text} )}
You can change your data on MongoDB in the server and your app will react and re-render for you.
You can connect to your MongoDB running `meteor mongo` in the terminal from your app folder or using a Mongo UI client, like [NoSQLBooster](https://nosqlbooster.com/downloads). Your embedded MongoDB is running in port `3001`.
See how to connect:
See your database:
You can double-click your collection to see the documents stored on it:
In the next step, we are going to create tasks using a form.
---
---
url: /tutorials/solid/1.creating-the-app.md
---
## 1: Creating the app
### 1.1: Install Meteor
First, we need to install Meteor by following this [installation guide](https://docs.meteor.com/about/install.html).
### 1.2: Create Meteor Project
The easiest way to setup Meteor with Solid is by using the command `meteor create` with the option `--solid` and your project name:
```shell
meteor create --solid simple-todos-solid
```
Meteor will create all the necessary files for you. With `--solid` option, Meteor generates a project using Solid and Rspack as the bundler, and this is the approach walked through in this tutorial. Using [the Rspack bundler](../../about/modern-build-stack/rspack-bundler-integration.md) is the default convention in Meteor 3.4+, as it improves dev speed, enables more build features, and provides better control over bundle size and configuration.
We provide the final app for both the Rspack and Meteor bundlers. This guide follows the Rspack version and reaches the same final state. The Meteor bundler version is for those who prefer the legacy bundler.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-solid/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-solid/tree/3.4-meteor).
:::
The files located in the `client` directory are setting up your client side (web), you can see for example `client/main.html` where Meteor is rendering your App main component into the HTML.
Also, check the `server` directory where Meteor is setting up the server side (Node.js), you can see the `server/main.js` which would be a good place to initialize your MongoDB database with some data. You don't need to install MongoDB as Meteor provides an embedded version of it ready for you to use.
You can now run your Meteor app using:
```shell
meteor
```
Don't worry, Meteor will keep your app in sync with all your changes from now on.
Take a quick look at all the files created by Meteor, you don't need to understand them now but it's good to know where they are.
Your Solid code will be located inside the `imports/ui` directory, and the `App.jsx` file will be the root component of your Solid To-do app.
### 1.3: Create Tasks
To start working on our todo list app, let’s replace the code of the default starter app with the code below. From there, we’ll talk about what it does.
First, let’s simplify our HTML entry point like so:
::: code-group
```html [client/main.html]
Todo List
- {task.text} )}
In Solid with Meteor, your main entry point is `client/main.js`, which imports `imports/ui/main.jsx`
to render your root Solid component `App.jsx` to a target element in the HTML like `` using Solid's `render` function.
Solid components are defined in `.jsx` files using JSX syntax, which can include JavaScript logic, imports, and reactive primitives. The JSX markup can use Solid's control flow components, such as `
Click on it and then select the phone that you want to simulate and in the top nav bar.
> You can also check your app in your personal cellphone. To do so, connect to your App using your local IP in the navigation browser of your mobile browser.
>
> This command should print your local IP for you on Unix systems
> `ifconfig | grep "inet " | grep -Fv 127.0.0.1 | awk '{print $2}'`
>
> On Microsoft Windows try this in a command prompt
> `ipconfig | findstr "IPv4 Address"`
You should see the following:
As you can see, everything is small, as we are not adjusting the view port for mobile devices. You can fix this and other similar issues by adding these lines to your `client/main.html` file, inside the `head` tag, after the `title`.
::: code-group
```html [client/main.html]
### 1.7: Hot Module Replacement
Starting from Meteor 3.4+, new apps use Rspack by default. It includes built-in Hot Module Replacement (HMR) and `solid-refresh`. This lets you see changes as you make them, even inside Solid components, without losing component state.
If you use a previous Meteor version, you can opt in to the [hot-module-replacement](https://docs.meteor.com/packages/hot-module-replacement) which is already added for you. This package updates the javascript modules in a running app that were modified during a rebuild. Reduces the feedback cycle while developing, so you can view and test changes quicker (it even updates the app before the build has finished). You are also not going to lose the state, your app code will be updated, and your state will be the same.
::: warning
`hot-module-replacement` can still be added to a Meteor app when using Meteor-Rspack with the `rspack` Atmosphere package enabled (3.4+). It acts as the HMR strategy for modules that are still compiled by the Meteor bundler, such as Atmosphere packages or any files explicitly kept on the Meteor bundler side.
:::
By default, when using Solid with Meteor in previous versions, reactivity is handled by integrating Solid's fine-grained signals and effects with Meteor's Tracker system. This allows real-time updates of the user's screen as data changes in the database without them having to manually refresh. You can achieve this using Tracker.autorun combined with Solid's createEffect or signals for seamless reactivity.
> You can read more about packages [here](https://docs.meteor.com/packages/).
You can also opt in to add the package [dev-error-overlay](https://atmospherejs.com/meteor/dev-error-overlay) when using previous versions, so you can see the errors in your web browser, so you can see the errors in your web browser.
```shell
meteor add dev-error-overlay
```
You can try to make some mistakes and then you are going to see the errors in the browser and not only in the console.
In the next step we are going to work with our MongoDB database to be able to store our tasks.
---
---
url: /tutorials/react/9.next-steps.md
---
## 9: Next Steps
You have completed the tutorial!
By now, you should have a good understanding of working with Meteor and React.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-react/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-react/tree/3.4-meteor).
:::
Here are some options for what you can do next:
- Check out the complete [documentation](https://v3-docs.meteor.com/) to learn more about Meteor 3.
- Read the [Galaxy Guide](https://galaxy-support.meteor.com/en/article/deploy-to-galaxy-18gd6e2/) to learn more about deploying your app.
- Join our community on the [Meteor Forums](https://forums.meteor.com/) and the [Meteor Lounge on Discord](https://discord.gg/hZkTCaVjmT) to ask questions and share your experiences.
We can't wait to see what you build next!
---
---
url: /tutorials/react/8.deploying.md
---
## 8: Deploying
Deploying a Meteor application is similar to deploying any other Node.js app that uses websockets. You can find deployment options in [our guide](/tutorials/deployment/deployment), including Meteor Up, Docker, and our recommended method, Galaxy.
In this tutorial, we will deploy our app on [Galaxy](https://www.meteor.com/hosting), which is our own cloud solution. Galaxy offers a free plan, so you can deploy and test your app. Pretty cool, right?
### 8.1: Create your account
You need a Meteor account to deploy your apps. If you don’t have one yet, you can [sign up here](https://cloud.meteor.com/?isSignUp=true).
With this account, you can access our package manager, [Atmosphere](https://atmospherejs.com/), [Forums](https://forums.meteor.com/) and more.
### 8.2: Set up MongoDB (Optional)
As your app uses MongoDB the first step is to set up a MongoDB database, Galaxy offers MongoDB hosting on a free plan for testing purposes, and you can also request for a production ready database that allows you to scale.
In any MongoDB provider you will have a MongoDB URL which you must use it. If you use the free option provided by Galaxy, the initial setup is done for you.
Galaxy MongoDB URL will be like this: `mongodb://username:
{user ? (
) : (
..
```
:::
### 7.5: Login Form style
Ok, let's style the login form now:
Wrap your pairs of label and input in `div`s so it will easier to control it on CSS. Do the same to the button tag.
::: code-group
```jsx [imports/ui/LoginForm.jsx]
```
:::
And then update the CSS:
::: code-group
```css [client/main.css]
.login-form {
display: flex;
flex-direction: column;
height: 100%;
justify-content: center;
align-items: center;
}
.login-form > div {
margin: 8px;
}
.login-form > div > label {
font-weight: bold;
}
.login-form > div > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
margin-top: 4px;
}
.login-form > div > input:focus {
outline: 0;
}
.login-form > div > button {
background-color: #62807e;
}
```
:::
Now your login form should be centralized and beautiful.
### 7.6: Server startup
Every task should have an owner from now on. So go to your database, as you learn before, and remove all the tasks from there:
`db.tasks.remove({});`
Change your `server/main.js` to add the seed tasks using your `meteorite` user as owner.
Make sure you restart the server after this change so `Meteor.startup` block will run again. This is probably going to happen automatically anyway as you are going to make changes in the server side code.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { Accounts } from "meteor/accounts-base";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = (taskText, user) =>
TasksCollection.insertAsync({
text: taskText,
userId: user._id,
createdAt: new Date(),
});
const SEED_USERNAME = "meteorite";
const SEED_PASSWORD = "password";
Meteor.startup(async () => {
if (!(await Accounts.findUserByUsername(SEED_USERNAME))) {
await Accounts.createUser({
username: SEED_USERNAME,
password: SEED_PASSWORD,
});
}
const user = await Accounts.findUserByUsername(SEED_USERNAME);
if ((await TasksCollection.find().countAsync()) === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach((taskText) => insertTask(taskText, user));
}
});
```
:::
See that we are using a new field called `userId` with our user `_id` field, we are also setting `createdAt` field.
### 7.7: Task owner
First, let's change our publication to publish the tasks only for the currently logged user. This is important for security, as you send only data that belongs to that user.
::: code-group
```js [/imports/api/TasksPublications.js]
Meteor.publish("tasks", function () {
const userId = this.userId;
if (!userId) {
return this.ready();
}
return TasksCollection.find({ userId });
});
```
:::
Now let's check if we have a `user` before trying to fetch any data:
::: code-group
```js [imports/ui/App.jsx]
..
const tasks = useTracker(() => {
if (!user) {
return [];
}
return TasksCollection.find(
hideCompleted ? hideCompletedFilter : {},
{
sort: { createdAt: -1 },
}
).fetch();
});
const pendingTasksCount = useTracker(() => {
if (!user) {
return 0;
}
..
});
..
```
:::
Also, update the `tasks.insert` method to include the field `userId` when creating a new task:
::: code-group
```js [imports/api/tasksMethods.js]
..
Meteor.methods({
"tasks.insert"(doc) {
return TasksCollection.insertAsync({
...doc,
userId: this.userId,
});
},
..
```
:::
### 7.8: Log out
We also can better organize our tasks by showing the username of the owner below our app bar. You can include a new `div` right after our `Fragment` start tag.
On this, you can add an `onClick` handler to logout the user as well. It is very straightforward, just call `Meteor.logout()` on it.
::: code-group
```js [imports/ui/App.jsx]
..
const logout = () => Meteor.logout();
return (
..
-
{tasks.map(task => (
{user.username} 🚪
..
```
:::
Remember to style your username as well.
::: code-group
```css [client/main.css]
.user {
display: flex;
align-self: flex-end;
margin: 8px 16px 0;
font-weight: bold;
cursor: pointer;
}
```
:::
Phew! You have done quite a lot in this step. Authenticated the user, set the user in the tasks, and provided a way for the user to log out.
Your app should look like this:
In the next step, we are going to learn how to deploy your app!
---
---
url: /tutorials/react/6.filter-tasks.md
---
## 6: Filter tasks
In this step, you will filter your tasks by status and show the number of pending tasks.
### 6.1: useState
First, you are going to add a button to show or hide the completed tasks from the list.
The `useState` function from React is the best way to keep the state of this button. It returns an array with two items, where the first element is the value of the state, and the second is a setter function that is how you are going to update your state. You can use _array destructuring_ to get these two back and already declare a variable for them.
Bear in mind that the names used for the constants do not belong to the React API, you can name them whatever you like.
Also, add a `button` below the task form that will display a different text based on the current state.
::: code-group
```js [imports/ui/App.jsx]
import React, { useState } from 'react';
..
export const App = () => {
const [hideCompleted, setHideCompleted] = useState(false);
..
You can also see all the messages that Meteor is sending and receiving from the server, this is useful for you to learn more about how Meteor works.
Install it in your Google Chrome browser using this [link](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf).
### 6.5: Pending tasks
Update the App component in order to show the number of pending tasks in the app bar.
You should avoid adding zero to your app bar when there are no pending tasks.
::: code-group
```js [imports/ui/App.jsx]
..
const pendingTasksCount = useTracker(() =>
TasksCollection.find(hideCompletedFilter).count()
);
const pendingTasksTitle = pendingTasksCount ? ` (${pendingTasksCount})` : '';
..
📝️ To Do List {pendingTasksTitle}
.. ``` ::: You could do both finds in the same `useTracker` and then return an object with both properties but to have a code that is easier to understand, we created two different trackers here. Your app should look like this:
In the next step we are going to include user access in your app.
---
---
url: /tutorials/react/5.styles.md
---
## 5: Styles
### 5.1: CSS
Our user interface up until this point has looked quite ugly. Let's add some basic styling which will serve as the foundation for a more professional looking app.
Replace the content of our `client/main.css` file with the one below, the idea is to have an app bar at the top, and a scrollable content including:
- form to add new tasks;
- list of tasks.
::: code-group
```css [client/main.css]
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
button {
font-weight: bold;
font-size: 1em;
border: none;
color: white;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
padding: 5px;
cursor: pointer;
}
button:focus {
outline: 0;
}
.app {
display: flex;
flex-direction: column;
height: 100vh;
}
.app-header {
flex-grow: 1;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.main {
display: flex;
flex-direction: column;
flex-grow: 1;
overflow: auto;
background: white;
}
.main::-webkit-scrollbar {
width: 0;
height: 0;
background: inherit;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
}
.app-bar {
display: flex;
justify-content: space-between;
}
.app-bar h1 {
font-size: 1.5em;
margin: 0;
display: inline-block;
margin-right: 1em;
}
.task-form {
display: flex;
margin: 16px;
}
.task-form > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
}
.task-form > input:focus {
outline: 0;
}
.task-form > button {
min-width: 100px;
height: 95%;
background-color: #315481;
}
.tasks {
list-style-type: none;
padding-inline-start: 0;
padding-left: 16px;
padding-right: 16px;
margin-block-start: 0;
margin-block-end: 0;
}
.tasks > li {
display: flex;
padding: 16px;
border-bottom: #eee solid 1px;
align-items: center;
}
.tasks > li > span {
flex-grow: 1;
}
.tasks > li > button {
justify-self: flex-end;
background-color: #ff3046;
}
```
:::
> If you want to learn more about this stylesheet check this article about [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/), and also this free [video tutorial](https://flexbox.io/) about it from [Wes Bos](https://twitter.com/wesbos).
>
> Flexbox is an excellent tool to distribute and align elements in your UI.
### 5.2: Applying styles
Now you need to add some elements around your components. You are going to add a `className` to your main div in the `App`, also a `header` element with a few `divs` around your `h1`, and a main `div` around your form and list. Check below how it should be, pay attention to the name of the classes, they need to be the same as in the CSS file:
::: code-group
```js [imports/ui/App.jsx]
..
return (
Welcome to Meteor!
-
{tasks.map((task) => (
📝️ To Do List
.. ``` ::: Your app should look like this:
In the next step, we are going to make this task list more interactive, for example, providing a way to filter tasks.
---
---
url: /tutorials/react/4.update-and-remove.md
---
## 4: Update and Remove
Up until now, you have only inserted documents into our collection. Let's take a look at how you can update and remove them by interacting with the user interface.
### 4.1: Add Checkbox
First, you need to add a `checkbox` element to your `Task` component.
> Be sure to add the `readOnly` attribute since we are not using `onChange` to update the state.
>
> We also have to force our `checked` prop to a `boolean` since React understands that an `undefined` value as inexistent, therefore causing the component to switch from uncontrolled to a controlled one.
>
> You are also invited to experiment and see how the app behaves for learning purposes.
You also want to receive a callback, a function that will be called when the checkbox is clicked.
::: code-group
```js [imports/ui/Task.jsx]
import React from "react";
export const Task = ({ task, onCheckboxClick }) => {
return (
-
{ tasks.map(task =>
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after text in your `Task` component and receive a callback function.
::: code-group
```js [imports/ui/Task.jsx]
import React from 'react';
export const Task = ({ task, onCheckboxClick, onDeleteClick }) => {
return (
..
{task.text}
..
```
:::
Now add the removal logic in the `App`, you need to have a function to delete the task and provide this function in your callback property in the `Task` component.
For that, let's create a new method called `tasks.delete`:
::: code-group
```javascript [imports/api/tasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
..
"tasks.delete"({ _id }) {
return TasksCollection.removeAsync(_id);
},
});
```
:::
Then, let's call this method inside a `handleDelete` function:
::: code-group
```js [imports/ui/App.jsx]
export const App = () => {
..
const handleDelete = ({ _id }) =>// [!code highlight]
Meteor.callAsync("tasks.delete", { _id });// [!code highlight]
..
-
{ tasks.map(task =>
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/react/3.forms-and-events.md
---
## 3: Forms and Events
All apps need to allow the user to perform some sort of interaction with the data that is stored. In our case, the first type of interaction is to insert new tasks. Without it, our To-Do app wouldn't be very helpful.
One of the main ways in which a user can insert or edit data on a website is through forms. In most cases, it is a good idea to use the `
);
};
```
:::
### 3.2: Update the App component
Then we can simply add this to our `App` component above your list of tasks:
::: code-group
```js [imports/ui/App.jsx]
import React from "react";
import { useTracker, useSubscribe } from "meteor/react-meteor-data";
import { TasksCollection } from "/imports/api/TasksCollection";
import { Task } from "./Task";
import { TaskForm } from "./TaskForm";
export const App = () => {
const isLoading = useSubscribe("tasks");
const tasks = useTracker(() => TasksCollection.find({}).fetch());
if (isLoading()) {
return Loading...
;
}
return (
Welcome to Meteor!
-
{tasks.map((task) => (
In the next step, we are going to update your tasks state and provide a way for users to remove tasks.
---
---
url: /tutorials/react/2.collections.md
---
## 2: Collections
Meteor already sets up MongoDB for you. In order to use our database, we need to create a _collection_, which is where we will store our _documents_, in our case our `tasks`.
> You can read more about collections [here](/api/collections).
In this step, we will implement all the necessary code to have a basic collection for our tasks up and running using React hooks.
### 2.1: Create Tasks Collection {#create-tasks-collection}
We can create a new collection to store our tasks by creating a new file at `imports/api/TasksCollection.js` which instantiates a new Mongo collection and exports it.
::: code-group
```js [imports/api/TasksCollection.js]
import { Mongo } from "meteor/mongo";
export const TasksCollection = new Mongo.Collection("tasks");
```
:::
Notice that we stored the file in the `imports/api` directory, which is a place to store API-related code, like publications and methods. You can name this folder as you want, this is just a choice.
You can delete the `links.js` file in this folder as we are not going to use this collection.
> You can read more about app structure and imports/exports [here](/tutorials/application-structure/).
### 2.2: Initialize Tasks Collection {#initialize-tasks-collection}
For our collection to work, you need to import it in the server so it sets some plumbing up.
You can either use `import "/imports/api/TasksCollection"` or `import { TasksCollection } from "/imports/api/TasksCollection"` if you are going to use on the same file, but make sure it is imported.
Now it is easy to check if there is data or not in our collection, otherwise, we can insert some sample data easily as well.
You don't need to keep the old content of `server/main.js`.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = (taskText) =>
TasksCollection.insertAsync({ text: taskText });
Meteor.startup(async () => {
if ((await TasksCollection.find().countAsync()) === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach(insertTask);
}
});
```
:::
So you are importing the `TasksCollection` and adding a few tasks to it iterating over an array of strings and for each string calling a function to insert this string as our `text` field in our `task` document.
### 2.3: Render Tasks Collection {#render-tasks-collection}
Now comes the fun part, you will render the tasks using a React Function Component and a Hook called `useTracker` from a package called [react-meteor-data](https://atmospherejs.com/meteor/react-meteor-data).
> Meteor works with Meteor packages and NPM packages, usually, Meteor packages are using Meteor internals or other Meteor packages.
This package is already included in the React skeleton (`meteor create yourproject`) so you don't need to add it but you can always add Meteor packages running `meteor add package-name`:
```shell
meteor add react-meteor-data
```
Now you are ready to import code from this package, when importing code from a Meteor package the only difference from NPM modules is that you need to prepend `meteor/` in the from part of your import.
The `useTracker` function exported by `react-meteor-data` is a React Hook that allows you to have reactivity in your React components. Every time the data changes through reactivity your component will re-render. Cool, right?
> For more information about React Hooks read [here](https://reactjs.org/docs/hooks-faq.html).
::: code-group
```javascript [imports/ui/App.jsx]
import React from "react";
import { useTracker } from "meteor/react-meteor-data";
import { TasksCollection } from "/imports/api/TasksCollection";
import { Task } from "./Task";
export const App = () => {
const tasks = useTracker(() => TasksCollection.find({}).fetch());
return (
Welcome to Meteor!
-
{tasks.map((task) => (
Loading...
;
}
...
}
```
As you can see, when subscribing to a publication using `useSubscribe` you'll get a `isLoading` function, that you can use to render some loading component before the data is ready.
> For more information on Publications/Subscriptions, please check our [docs](/api/meteor#pubsub).
See how your app should look like now:
You can change your data on MongoDB in the server and your app will react and re-render for you.
You can connect to your MongoDB running `meteor mongo` in the terminal from your app folder or using a Mongo UI client, like [NoSQLBooster](https://nosqlbooster.com/downloads). Your embedded MongoDB is running in port `3001`.
See how to connect:
See your database:
You can double-click your collection to see the documents stored on it:
In the next step, we are going to create tasks using a form.
---
---
url: /tutorials/react/1.creating-the-app.md
---
## 1: Creating the app
### 1.1: Install Meteor {#install-meteor}
First, we need to install Meteor.
If you don't have Meteor installed, you can install it by running:
```shell
npx meteor
```
### 1.2: Create Meteor Project {#create-meteor-project}
The easiest way to setup Meteor with React is by using the command `meteor create` with the option `--react` and your project name (you can also omit the `--react` option since it is the default):
```shell
meteor create simple-todos-react
```
Meteor will create all the necessary files for you. By default, Meteor generates a project using React and Rspack as the bundler, and this is the approach walked through in this tutorial. Using [the Rspack bundler](../../about/modern-build-stack/rspack-bundler-integration.md) is the default convention in Meteor 3.4+, as it improves dev speed, enables more build features, and provides better control over bundle size and configuration.
We provide the final app for both the Rspack and Meteor bundlers. This guide follows the Rspack version and reaches the same final state. The Meteor bundler version is for those who prefer the legacy bundler.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-react/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-react/tree/3.4-meteor).
:::
The files located in the `client` directory are setting up your client side (web), you can see for example `client/main.jsx` where Meteor is rendering your App main component into the HTML.
Also, check the `server` directory where Meteor is setting up the server side (Node.js), you can see the `server/main.js` is initializing your MongoDB database with some data. You don't need to install MongoDB as Meteor provides an embedded version of it ready for you to use.
You can now run your Meteor app using:
```shell
meteor run
```
Don't worry, Meteor will keep your app in sync with all your changes from now on.
Your React code will be located inside the `imports/ui` directory, and `App.jsx` file is the root component of your React To-do app.
Take a quick look at all the files created by Meteor, you don't need to understand them now but it's good to know where they are.
### 1.3: Create Task Component {#create-task-component}
You will make your first change now. Create a new file called `Task.jsx` in your `ui` folder.
This file will export a React component called `Task` that will represent one task in your To-Do list.
::: code-group
```js [imports/ui/Task.jsx]
import React from "react";
export const Task = ({ task }) => {
return Welcome to Meteor!
-
{ tasks.map(task =>
Todo List
If your computer is fast enough, it's possible that when it sets up the default tasks a few will have the same date. That will cause them to non-deterministically "jump around" in the UI as you toggle checkboxes and the UI reactively updates. To make it stable, you can add a secondary sort on the `_id` of the task:
::: code-group
```jsx [imports/ui/App.jsx]
...
Tracker.autorun(async () => {
setIsReady(subscription.ready());
setTasks(await TasksCollection.find({}, { sort: { createdAt: -1, _id: -1 } }).fetchAsync()); // [!code highlight]
});
...
```
:::
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after the `label` in your `Task` component and a `deleteTask` function.
::: code-group
```jsx [imports/ui/Task.jsx]
import { Meteor } from "meteor/meteor";
export const Task = (props) => {
const { task } = props;
const toggleChecked = async () => {
await Meteor.callAsync("tasks.toggleChecked", { _id: task._id, isChecked: task.isChecked });
};
const deleteTask = async () => { // [!code highlight]
await Meteor.callAsync("tasks.delete", { _id: task._id }); // [!code highlight]
}; // [!code highlight]
return (
### 4.4: Getting data in event handlers
In a collection, every inserted document has a unique `_id` field that can refer to that specific document. Inside the component, the `task` prop provides access to the task object, including its `_id`
and other fields like `isChecked` and `text`. We use these to call Meteor methods for updating or removing the specific task.
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/svelte/9.next-steps.md
---
## 9: Next Steps
You have completed the tutorial!
By now, you should have a good understanding of working with Meteor and Svelte.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-meteor).
:::
Here are some options for what you can do next:
- Check out the complete [documentation](https://v3-docs.meteor.com/) to learn more about Meteor 3.
- Read the [Galaxy Guide](https://galaxy-support.meteor.com/en/article/deploy-to-galaxy-18gd6e2/) to learn more about deploying your app.
- Join our community on the [Meteor Forums](https://forums.meteor.com/) and the [Meteor Lounge on Discord](https://discord.gg/hZkTCaVjmT) to ask questions and share your experiences.
We can't wait to see what you build next!
---
---
url: /tutorials/svelte/8.deploying.md
---
## 8: Deploying
Deploying a Meteor application is similar to deploying any other Node.js app that uses websockets. You can find deployment options in [our guide](/tutorials/deployment/deployment), including Meteor Up, Docker, and our recommended method, Galaxy.
In this tutorial, we will deploy our app on [Galaxy](https://galaxycloud.app/), which is our own cloud solution. Galaxy offers a free plan, so you can deploy and test your app. Pretty cool, right?
### 8.1: Create your account
You need a Meteor account to deploy your apps. If you don’t have one yet, you can [sign up here](https://cloud.meteor.com/?isSignUp=true).
With this account, you can access our package manager, [Atmosphere](https://atmospherejs.com/), [Forums](https://forums.meteor.com/) and more.
### 8.2: Set up MongoDB (Optional)
As your app uses MongoDB the first step is to set up a MongoDB database, Galaxy offers MongoDB hosting on a free plan for testing purposes, and you can also request for a production ready database that allows you to scale.
In any MongoDB provider you will have a MongoDB URL which you must use. If you use the free option provided by Galaxy, the initial setup is done for you.
Galaxy MongoDB URL will be like this: `mongodb://username:
{#if currentUser}
-
{#if subIsReady}
{#each tasks as task (task._id)}
Loading ...
{/if}
{#if currentUser}
In the next step, we are going to learn how to deploy your app!
---
---
url: /tutorials/svelte/6.filter-tasks.md
---
## 6: Filter tasks
In this step, you will filter your tasks by status and show the number of pending tasks.
### 6.1: Reactive State
First, you will add a button to show or hide the completed tasks from the list.
In Svelte, we can manage component state using reactive variables directly in the `
```
:::
Then, add the button in the markup to toggle the state:
::: code-group
```html [imports/ui/App.svelte]
```
:::
You may notice we’re using {#if} (a conditional block) for the button text. You can learn more about Svelte's conditional rendering [here](https://svelte.dev/docs#client-side-component-api).
### 6.2: Button style
You should add some style to your button so it does not look gray and without a good contrast. You can use the styles below as a reference:
::: code-group
```css [client/main.css]
.filter {
display: flex;
justify-content: center;
}
.filter > button {
background-color: #62807e;
}
```
:::
### 6.3: Filter Tasks
Now, update the reactive tasks fetch to apply the filter if `hideCompleted` is true. We'll also add a reactive variable for the incomplete count.
::: code-group
```html [imports/ui/App.svelte]
```
:::
### 6.4: Meteor Dev Tools Extension
You can install an extension to visualize the data in your Mini Mongo.
[Meteor DevTools Evolved](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf) will help you to debug your app as you can see what data is on Mini Mongo.
You can also see all the messages that Meteor is sending and receiving from the server, this is useful for you to learn more about how Meteor works.
Install it in your Google Chrome browser using this [link](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf).
### 6.5: Pending tasks
Update the App component in order to show the number of pending tasks in the app bar.
You should avoid adding zero to your app bar when there are no pending tasks. Use the reactive `incompleteDisplay` in the header:
::: code-group
```html [imports/ui/App.svelte]
```
:::
Your app should look like this:
In the next step we are going to include user access in your app.
---
---
url: /tutorials/svelte/5.styles.md
---
## 5: Styles
### 5.1: CSS
Our user interface up until this point has looked quite ugly. Let's add some basic styling which will serve as the foundation for a more professional looking app.
Replace the content of our `client/main.css` file with the one below, the idea is to have an app bar at the top, and a scrollable content including:
- form to add new tasks;
- list of tasks.
::: code-group
```css [client/main.css]
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
button {
font-weight: bold;
font-size: 1em;
border: none;
color: white;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
padding: 5px;
cursor: pointer;
}
button:focus {
outline: 0;
}
.app {
display: flex;
flex-direction: column;
height: 100vh;
}
.app-header {
flex-grow: 1;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.main {
display: flex;
flex-direction: column;
flex-grow: 1;
overflow: auto;
background: white;
}
.main::-webkit-scrollbar {
width: 0;
height: 0;
background: inherit;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
}
.app-bar {
display: flex;
justify-content: space-between;
}
.app-bar h1 {
font-size: 1.5em;
margin: 0;
display: inline-block;
margin-right: 1em;
}
.task-form {
display: flex;
margin: 16px;
}
.task-form > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
}
.task-form > input:focus {
outline: 0;
}
.task-form > button {
min-width: 100px;
height: 95%;
background-color: #315481;
}
.tasks {
list-style-type: none;
padding-inline-start: 0;
padding-left: 16px;
padding-right: 16px;
margin-block-start: 0;
margin-block-end: 0;
}
.tasks > li {
display: flex;
padding: 16px;
border-bottom: #eee solid 1px;
align-items: center;
}
.tasks > li > label {
flex-grow: 1;
}
.tasks > li > button {
justify-self: flex-end;
background-color: #ff3046;
}
```
:::
> If you want to learn more about this stylesheet check this article about [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/), and also this free [video tutorial](https://flexbox.io/) about it from [Wes Bos](https://twitter.com/wesbos).
>
> Flexbox is an excellent tool to distribute and align elements in your UI.
### 5.2: Applying styles
Now you need to add some elements around your components. You are going to add a `class` to your main `div` in the `App.svelte`, also a `header` element with a few `div` elements around your `h1`, and a main `div` around your form and list. Check below how it should be; pay attention to the name of the classes, they need to be the same as in the CSS file:
::: code-group
```html [imports/ui/App.svelte]
```
:::
Your app should look like this:
In the next step, we are going to make this task list more interactive, for example, providing a way to filter tasks.
---
---
url: /tutorials/svelte/4.update-and-remove.md
---
## 4: Update and Remove
Up until now, you have only inserted documents into our collection. Let's take a look at how you can update and remove them by interacting with the user interface.
### 4.1: Add Checkbox
First, you need to add a `checkbox` element to your `Task` component.
Next, let’s create a new file for our `task` template in `imports/ui/Task.svelte`, so we can start to separate the logic in our app.
::: code-group
```html [imports/ui/Task.svelte]
```
:::
Now, update `App.svelte` to import and use the `Task` component in the {#each} loop. Remove the old `` markup.
::: code-group
```html [imports/ui/App.svelte]
```
:::
### 4.2: Toggle Checkbox
Now you can update your task document by toggling its `isChecked` field.
First, create a new method called `tasks.toggleChecked` to update the `isChecked` property.
::: code-group
```js [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
...
"tasks.toggleChecked"({ _id, isChecked }) {
return TasksCollection.updateAsync(_id, {
$set: { isChecked: !isChecked },
});
},
});
```
:::
In `Task.svelte` (as shown above), we've added an `on:change` handler that calls the method to toggle the checked state.
Toggling checkboxes should now persist in the DB even if you refresh the web browser.
Your app should look like this:
If your computer is fast enough, it's possible that when it sets up the default tasks a few will have the same date. That will cause them to non-deterministically "jump around" in the UI as you toggle checkboxes and the UI reactively updates. To make it stable, you can add a secondary sort on the `_id` of the task:
::: code-group
```html [imports/ui/App.svelte]
```
:::
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after the `label` in your `Task` component and a `deleteTask` function between the `script` tags.
::: code-group
```html [imports/ui/Task.svelte]
```
:::
Next you need to have a function to delete the task. For that, let's create a new method called `tasks.delete`:
::: code-group
```js [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
...
"tasks.delete"({ _id }) {
return TasksCollection.removeAsync(_id);
},
});
```
:::
Now the removal logic is handled in `Task.svelte` via the `on:click` event on the delete button, which calls the Meteor method.
Your app should look like this:
### 4.4: Getting data in event handlers
In a collection, every inserted document has a unique `_id` field that can refer to that specific document. Inside the component, the `task` prop provides access to the task object, including its `_id`
and other fields like `isChecked` and `text`. We use these to call Meteor methods for updating or removing the specific task.
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/svelte/3.forms-and-events.md
---
## 3: Forms and Events
All apps need to allow the user to perform some sort of interaction with the data that is stored. In our case, the first type of interaction is to insert new tasks. Without it, our To-Do app wouldn't be very helpful.
One of the main ways in which a user can insert or edit data on a website is through forms. In most cases, it is a good idea to use the `
...
```
:::
Let's now add an `addTask()` function handler inside the script tags below the imports. It will call a Meteor method `tasks.insert` that isn't yet created but we'll soon make:
::: code-group
```html [imports/ui/App.svelte]
...
let newTask = '';
async function addTask(event) {
event.preventDefault();
if (newTask.trim()) {
await Meteor.callAsync("tasks.insert", {
text: newTask,
createdAt: new Date(),
});
newTask = '';
}
}
...
```
:::
Altogether, our file should look like:
::: code-group
```html [imports/ui/App.svelte]
```
:::
In the code above, we've integrated the form directly into the `App.svelte`
component, positioning it above the task list. We're using Svelte's `bind:value`
for two-way binding on the input and an `on:submit` handler for form submission.
### 3.2: Update the Stylesheet
You also can style it as you wish. For now, we only need some margin at the top so the form doesn't seem off the mark. Add the CSS class `.task-form`, this needs to be the same name in your `class` attribute in the form element.
::: code-group
```css [client/main.css]
...
.task-form {
margin-top: 1rem;
}
...
```
:::
### 3.3: Add Submit Handler
Now let's create a function to handle the form submit and insert a new task into the database. To do it, we will need to implement a Meteor Method.
Methods are essentially RPC calls to the server that let you perform operations on the server side securely. You can read more about Meteor Methods [here](/tutorials/methods/methods).
To create your methods, you can create a file called `TasksMethods.js`.
::: code-group
```javascript [imports/api/TasksMethods.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.methods({
"tasks.insert"(doc) {
return TasksCollection.insertAsync(doc);
},
});
```
:::
Remember to import your method on the `main.js` server file, delete the `insertTask` function, and invoke the new meteor method inside the `forEach` block.
::: code-group
```javascript [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
import "../imports/api/TasksPublications";
import "../imports/api/TasksMethods"; // [!code highlight]
Meteor.startup(async () => {
if ((await TasksCollection.find().countAsync()) === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach((taskName) => {
Meteor.callAsync("tasks.insert", { // [!code highlight]
text: taskName, // [!code highlight]
createdAt: new Date(), // [!code highlight]
});
});
}
});
```
:::
Inside the `forEach` function, we are adding a task to the `tasks` collection by calling `Meteor.callAsync()`. The first argument is the name of the method we want to call, and the second argument is the text of the task.
Also, insert a date `createdAt` in your `task` document so you know when each task was created.
Now we need to import `TasksMethods.js` and add a listener to the `submit` event on the form:
::: code-group
```html [imports/ui/App.svelte]
```
:::
In the `addTask` function (shown in 3.1), we prevent the default form submission, get the input value, call the Meteor method to insert the task optimistically, and clear the input.
Meteor methods execute optimistically on the client using MiniMongo while simultaneously calling the server. If the server call fails, MiniMongo rolls back the change, providing a speedy user experience. It's a bit like [rollback netcode](https://glossary.infil.net/?t=Rollback%20Netcode) in fighting video games.
### 3.4: Show Newest Tasks First
Now you just need to make a change that will make users happy: we need to show the newest tasks first. We can accomplish this quite quickly by sorting our [Mongo](/tutorials/collections/collections#mongo-collections) query.
::: code-group
```html [imports/ui/App.svelte]
```
:::
Your app should look like this:
In the next step, we are going to update your tasks state and provide a way for users to remove tasks.
---
---
url: /tutorials/svelte/2.collections.md
---
## 2: Collections
Meteor already sets up MongoDB for you. In order to use our database, we need to create a _collection_, which is where we will store our _documents_, in our case our `tasks`.
> You can read more about collections [here](/api/collections).
In this step we will implement all the necessary code to have a basic collection for our tasks up and running.
### 2.1: Create Tasks Collection
We can create a new collection to store our tasks by creating a new file at `imports/api/TasksCollection.js` which instantiates a new Mongo collection and exports it.
::: code-group
```js [imports/api/TasksCollection.js]
import { Mongo } from "meteor/mongo";
export const TasksCollection = new Mongo.Collection("tasks");
```
:::
Notice that we stored the file in the `imports/api` directory, which is a place to store API-related code, like publications and methods. You can name this folder as you want, this is just a choice.
If there is a `imports/api/links.js` file from the starter project, you can delete that now as we don't need it.
> You can read more about app structure and imports/exports [here](/tutorials/application-structure/).
### 2.2: Initialize Tasks Collection
For our collection to work, you need to import it in the server so it sets some plumbing up.
You can either use `import "/imports/api/TasksCollection"` or `import { TasksCollection } from "/imports/api/TasksCollection"` if you are going to use on the same file, but make sure it is imported.
Now it is easy to check if there is data or not in our collection, otherwise, we can insert some sample data easily as well.
You don't need to keep the old content of `server/main.js`.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = async (taskText) =>
await TasksCollection.insertAsync({ text: taskText });
Meteor.startup(async () => {
if (await TasksCollection.find().countAsync() === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach(insertTask);
}
});
```
:::
So you are importing the `TasksCollection` and adding a few tasks to it iterating over an array of strings and for each string calling a function to insert this string as our `text` field in our `task` document.
### 2.3: Render Tasks Collection
Now comes the fun part, you will render the tasks with Svelte. That will be pretty simple.
In your `App.svelte` file, import the `TasksCollection` file and, instead of returning a static array, return the tasks saved in the database:
::: code-group
```html [imports/ui/App.svelte]
```
:::
But wait! Something is missing. If you run your app now, you'll see that you don't render any tasks.
That's because we need to publish our data to the client.
> For more information on Publications/Subscriptions, please check our [docs](/api/meteor#pubsub).
Meteor doesn't need REST calls. It instead relies on synchronizing the MongoDB on the server with a MiniMongoDB on the client. It does this by first publishing collections on the server and then subscribing to them on the client.
First, create a publication for our tasks:
::: code-group
```javascript [imports/api/TasksPublications.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "./TasksCollection";
Meteor.publish("tasks", function () {
return TasksCollection.find();
});
```
:::
Now, we need to import this file in our server:
::: code-group
```js [server/main.js]
...
import { TasksCollection } from '/imports/api/TasksCollection';
import "../imports/api/TasksPublications"; // [!code highlight]
const insertTask = taskText => TasksCollection.insertAsync({ text: taskText });
...
```
:::
The only thing left is subscribe to this publication, which we've already added in `App.svelte` using Tracker and lifecycle hooks:
::: code-group
```javascript [imports/ui/App.svelte]
...
onMount(() => {
handle = Meteor.subscribe("tasks");
computation = Tracker.autorun(() => {
// Reactive code here
});
});
...
```
:::
See how your app should look like now:
You can change your data on MongoDB in the server and your app will react and re-render for you.
You can connect to your MongoDB running `meteor mongo` in the terminal from your app folder or using a Mongo UI client, like [NoSQLBooster](https://nosqlbooster.com/downloads). Your embedded MongoDB is running in port `3001`.
See how to connect:
See your database:
You can double-click your collection to see the documents stored on it:
In the next step, we are going to create tasks using a form.
---
---
url: /tutorials/svelte/1.creating-the-app.md
---
## 1: Creating the app
### 1.1: Install Meteor
First, we need to install Meteor by following this [installation guide](https://docs.meteor.com/about/install.html).
### 1.2: Create Meteor Project
The easiest way to setup Meteor with Svelte is by using the command `meteor create` with the option `--svelte` and your project name:
```shell
meteor create --svelte simple-todos-svelte
```
Meteor will create all the necessary files for you. With `--svelte` option, Meteor generates a project using Svelte 5 and Rspack as the bundler, and this is the approach walked through in this tutorial. Using [the Rspack bundler](../../about/modern-build-stack/rspack-bundler-integration.md) is the default convention in Meteor 3.4+, as it improves dev speed, enables more build features, and provides better control over bundle size and configuration.
We provide the final app for both the Rspack and Meteor bundlers. This guide follows the Rspack version and reaches the same final state. The Meteor bundler version is for those who prefer the legacy bundler.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-meteor).
:::
The files located in the `client` directory are setting up your client side (web), you can see for example `client/main.html` where Meteor is rendering your App main component into the HTML.
Also, check the `server` directory where Meteor is setting up the server side (Node.js), you can see the `server/main.js` which would be a good place to initialize your MongoDB database with some data. You don't need to install MongoDB as Meteor provides an embedded version of it ready for you to use.
You can now run your Meteor app using:
```shell
meteor
```
Don't worry, Meteor will keep your app in sync with all your changes from now on.
Take a quick look at all the files created by Meteor, you don't need to understand them now but it's good to know where they are.
Your Svelte code will be located inside the `imports/ui` directory, and the `App.svelte` file will be the root component of your Svelte To-do app.
### 1.3: Create Tasks
To start working on our todo list app, let’s replace the code of the default starter app with the code below. From there, we’ll talk about what it does.
First, let’s simplify our HTML entry point like so:
::: code-group
```html [client/main.html]
Simple todo
```
:::
The `client/main.js` file should import and render the main Svelte component:
::: code-group
```js [client/main.js]
import { Meteor } from 'meteor/meteor';
import App from '../imports/ui/App.svelte';
import { mount, unmount } from 'svelte';
let app; // will hold the mounted instance
Meteor.startup(() => {
const target = document.getElementById('app');
// (Re)mount
app = mount(App, { target });
// Clean up on HMR so we don't double-mount
if (import.meta.webpackHot) {
import.meta.webpackHot.accept();
import.meta.webpackHot.dispose(() => {
if (app) {
// pass the instance you got from mount()
unmount(app, { outro: false }); // set outro:true if you want transitions
app = null;
}
// optional: clear target to be extra safe
target.innerHTML = '';
});
}
});
```
:::
Inside the `imports/ui` folder let us modify `App.svelte` to display a header and a list of tasks:
::: code-group
```html [imports/ui/App.svelte]
```
:::
We just modified our main Svelte component `App.svelte`, which will be rendered into the `#app` div in the body. It shows a header and a list of tasks. For now, we're using static sample data to display the tasks.
### 1.4: View Sample Tasks
As you are not connecting to your server and database yet, we’ve defined some sample data directly in `App.svelte` to render a list of tasks.
At this point meteor should be running on port 3000 so you can visit the running app and see your list with three tasks displayed at [http://localhost:3000/](http://localhost:3000/) - but if meteor is not running, go to your terminal and move to the top directory of your project and type `meteor` then press return to launch the app.
All right! Let’s find out what all these bits of code are doing!
### 1.5: Rendering Data
In Svelte with Meteor, your main entry point is `client/main.js`, which imports and mounts your root Svelte component `App.svelte` to a target element in the HTML like ``
Svelte components are defined in `.svelte` files, which can include `
```
```javascript [index.js]
/* global WebApp Assets */
import crypto from "crypto";
import express from "express";
const router = express.Router();
router.get("/", async function (req, res, next) {
const buf = await Assets.getTextAsync("index.html");
if (buf.length > 0) {
const eTag = crypto.createHash("md5").update(buf).digest("hex");
if (req.headers["if-none-match"] === eTag) {
res.writeHead(304, "Not Modified");
return res.end();
}
res.writeHead(200, {
ETag: eTag,
"Content-Type": "text/html",
});
return res.end(buf);
}
return res.end("Index page not found!");
});
WebApp.handlers.use(router);
```
:::
There are a couple things to think about with this approach.
We're reading the contents of index.html using the [Assets](../api/assets.md) module that makes it really easy to read files out of the _private_ root folder.
We're using the [connect-route](https://www.npmjs.com/package/connect-route) NPM package to simplify WebApp route processing. But you can use any package you want to understand what is being requested.
And finally, if you decide to use this technique you'll want to make sure you understand how conflicting client side routing will affect user experience.
### React SSR Optimization (Meteor 3.4)
**Experimental: Disable Boilerplate Response** ([PR#13855](https://github.com/meteor/meteor/pull/13855))
Meteor 3.4 introduces an experimental configuration option to improve React Server-Side Rendering (SSR) performance by disabling the default boilerplate HTML response.
When using React SSR with packages like `server-render`, you may want to completely control the HTML output without Meteor's default boilerplate injection. Enable this with:
```js
// server/main.js
import { WebApp } from 'meteor/webapp';
WebApp.addHtmlAttributeHook(() => ({
disableBoilerplateResponse: true
}));
```
**Benefits:**
- **Full SSR Control**: Complete control over the HTML output for SSR frameworks
- **Better Performance**: Reduces overhead by skipping boilerplate generation
- **Cleaner Output**: No automatic script/link injection, allowing custom placement
**Use Cases:**
- Advanced React SSR implementations
- Custom HTML structure requirements
- Integration with SSR frameworks like Next.js patterns in Meteor
**Important Notes:**
- This is an experimental feature and may change in future releases
- When enabled, you're responsible for including all necessary scripts and assets
- Best used with the `server-render` package for full SSR implementations
Example with server-render:
```js
import { onPageLoad } from 'meteor/server-render';
import { renderToString } from 'react-dom/server';
import { WebApp } from 'meteor/webapp';
WebApp.addHtmlAttributeHook(() => ({
disableBoilerplateResponse: true
}));
onPageLoad(sink => {
const html = renderToString()` multiple times, or with an array (e.g., `api.versionsFrom(['3.0', '2.14'])`). Meteor will interpret this to mean that the package will work with packages from all the listed releases.
### Semantic versioning and version constraints
Meteor's package system relies heavily on [Semantic Versioning](http://semver.org/), or SemVer. When one package declares a dependency on another, it always comes with a version constraint. These version constraints are then solved by Meteor's Version Solver to arrive at a set of package versions that meet all of the requirements.
The mental model here is:
1. **The major version must always match exactly.** If package `a` depends on `b@2.0.0`, the constraint will only be satisfied if the version of package `b` starts with a `2`. This means that you can never have two different major versions of a package in the same app.
2. **The minor and patch version numbers must be greater or equal to the requested version.** If the dependency requests version `2.1.3`, then `2.1.4` and `2.2.0` will work, but `2.0.4` and `2.1.2` will not.
If your package supports multiple major versions of a dependency, you can supply both versions to `api.use` like so:
```js
api.use('blaze@1.0.0 || 2.0.0');
```
### npm dependencies
Meteor packages can include npm packages to use JavaScript code from outside the Meteor package ecosystem or to include JavaScript code with native dependencies. Use `Npm.depends` at the top level of your `package.js` file:
```js
Npm.depends({
'github': '0.2.4'
});
```
If you want to use a local npm package, for example during development, you can give a directory instead of a version number:
```js
Npm.depends({
'my-package': 'file:///home/user/npms/my-package'
});
```
You can import the dependency from within your package code in the same way that you would inside an application:
```js
import github from 'github';
```
### Development-only npm dependencies (Meteor 3.4+)
**New in Meteor 3.4** ([PR#13797](https://github.com/meteor/meteor/pull/13797)): Use `Npm.devDepends()` to declare npm dependencies that are only needed during development. These dependencies will be excluded from production builds, reducing your production bundle size.
```js
// Production dependencies - always included
Npm.depends({
'lodash': '4.17.21',
'moment': '2.29.4'
});
// Development-only dependencies - excluded from production
Npm.devDepends({
'debug-tool': '2.0.0',
'dev-helper': '1.5.0',
'mock-data-generator': '3.1.0'
});
```
**When to use `Npm.devDepends()`:**
- Development debugging libraries
- Mock data generators
- Development server utilities
- Testing helpers that aren't used in production
- Development-only logging frameworks
**Benefits:**
- **Smaller Production Bundles**: Dev dependencies don't ship to production
- **Faster Production Builds**: Less code to transpile and minify
- **Clear Dependency Management**: Explicit separation between production and development dependencies
**Example - Complete Package with Dev Dependencies:**
```js
// packages/username:data-layer/package.js
Package.describe({
name: 'username:data-layer',
version: '1.0.0',
summary: 'Data access layer with development tools'
});
// Production dependencies
Npm.depends({
'lodash': '4.17.21',
'validator': '13.7.0'
});
// Development-only dependencies
Npm.devDepends({
'faker': '5.5.3', // For generating test data
'debug': '4.3.4', // For development logging
'pretty-format': '27.5.1' // For formatting debug output
});
Package.onUse(function(api) {
api.versionsFrom('3.4');
api.use(['ecmascript', 'mongo']);
api.mainModule('data-layer.js');
});
```
```js
// packages/username:data-layer/data-layer.js
import { Meteor } from 'meteor/meteor';
import _ from 'lodash';
import validator from 'validator';
// These imports will only work in development
let faker, debug, prettyFormat;
if (Meteor.isDevelopment) {
faker = require('faker');
debug = require('debug')('data-layer');
prettyFormat = require('pretty-format');
}
export const DataLayer = {
validateEmail(email) {
return validator.isEmail(email);
},
// Development-only method
generateTestUsers(count) {
if (!Meteor.isDevelopment) {
throw new Meteor.Error('not-available', 'Only available in development');
}
return _.times(count, () => ({
name: faker.name.findName(),
email: faker.internet.email(),
createdAt: new Date()
}));
},
// Development-only debugging
debugQuery(query) {
if (Meteor.isDevelopment && debug) {
debug('Query:', prettyFormat(query));
}
}
};
```
**Important Notes:**
- `Npm.devDepends()` dependencies are available during development via `require()` or dynamic `import()`
- Always check `Meteor.isDevelopment` before using dev dependencies in your code
- Dev dependencies are still installed in `node_modules` but excluded from production builds
- Using a dev dependency in production code without the development check will cause runtime errors in production
### Peer npm dependencies
`Npm.depends()` is fairly rigid (you can only depend on an exact version), and will typically result in multiple versions of a package being installed if many different Atmosphere packages depend on the same npm package. This makes it less than ideal to use on the client, where it's impractical to ship multiple copies of the same package code to the browser.
To avoid this problem as a package author, you can request that users of your package have installed the npm package you want to use at the application level. This is similar to a peer dependency of an npm package. You can use the `tmeasday:check-npm-versions` package to ensure that they've done this, and to warn them if not.
For instance, if you are writing a React package, you should not directly depend on `react`, but instead use `check-npm-versions` to check the user has installed it:
```js
import { checkNpmVersions } from 'meteor/tmeasday:check-npm-versions';
checkNpmVersions({
'react': '18.x'
}, 'my:awesome-package');
// If you are using the dependency in the same file, you'll need to use require
const React = require('react');
```
## Cordova plugins
Atmosphere packages can include Cordova plugins to ship native code for the Meteor mobile app container. This way, you can interact with the native camera interface, use the gyroscope, save files locally, and more.
Include Cordova plugins in your Meteor package by using `Cordova.depends`.
Read more about using Cordova in the [mobile guide](/about/cordova).
## Testing packages
Meteor has a test mode for packages invoked with the `meteor test-packages` command. Navigate to your package's directory and then use the command to run a special app containing only a "test" version of your package.
If you are using Tinytest for your package's tests, you can run:
```bash
meteor test-packages ./
```
If you are using a different testing framework for your package's tests, you'll need to specify a `driver-package`. For example, if you are using Mocha:
```bash
meteor test-packages ./ --driver-package meteortesting:mocha
```
When your package starts in test mode, rather than loading the `onUse` block, Meteor loads the `onTest` block:
```js
Package.onTest(function(api) {
// You almost definitely want to depend on the package itself,
// this is what you are testing!
api.use('my-package');
// You should also include any packages you need to use in the test code
api.use(['ecmascript', 'random', 'meteortesting:mocha']);
// Finally add an entry point for tests
api.mainModule('my-package-tests.js');
});
```
From within your test entry point, you can import other files as you would in the package proper.
You can also use [`mtest`](https://github.com/zodern/mtest) to test your packages:
```bash
mtest --package ./ --once 3.0
```
This helps immensely if you'd like to test your package in CI/CD setup.
You can read more about testing in Meteor in the [Testing article](/tutorials/testing/testing).
## Publishing your package
To publish your package to Atmosphere for the first time, run `meteor publish --create` from the package directory. The package name must follow the format of `username:my-package` and the package must contain a SemVer version number. When you want to publish an update to your package, change the version number in `package.js` and then run `meteor publish`.
> Note that if you have a local `node_modules` directory in your package, remove it before running `meteor publish`. While local `node_modules` directories are allowed in Meteor packages, their paths can collide with the paths of `Npm.depends` dependencies when published.
### Cache format
If you've ever looked inside Meteor's package cache at `~/.meteor/packages`, you know that the on-disk format of a built Meteor package is completely different from the way the source code looks when you're developing the package. The idea is that the target format of a package can remain consistent even if the API for development changes.
## Local packages
As an alternative to publishing your package on Atmosphere, if you want to keep your package private, you can place it in your Meteor app in the `packages/` directory, for instance `packages/foo/`, and then add it to your app with `meteor add foo`.
### Overriding published packages with a local version
If you need to modify an Atmosphere package to do something that the published version doesn't do, you can edit a local version of the package on your computer.
A Meteor app can load Atmosphere packages in one of three ways, and it looks for a matching package name in the following order:
1. Package source code in the `packages/` directory inside your app.
2. Package source code in directories indicated by setting a `METEOR_PACKAGE_DIRS` environment variable before running any `meteor` command. You can add multiple directories by separating the paths with a `:` on OSX or Linux, or a `;` on Windows. For example: `METEOR_PACKAGE_DIRS=../first/directory:../second/directory`.
3. Pre-built package from Atmosphere. The package is cached in `~/.meteor/packages` on Mac/Linux or `%LOCALAPPDATA%\.meteor\packages` on Windows, and only loaded into your app as it is built.
You can use (1) or (2) to override the version from Atmosphere. You can even do this to load patched versions of Meteor core packages - just copy the code of the package from [Meteor's GitHub repository](https://github.com/meteor/meteor/tree/devel/packages), and edit away.
---
---
url: /packages/5.writing-npm-packages.md
---
# Writing npm Packages
This guide covers how to create, develop, and publish npm packages for use in Meteor applications.
## Creating a new npm package
To create a new npm package:
```bash
mkdir my-package
cd my-package/
meteor npm init
```
The last command creates a `package.json` file and prompts you for the package information. You may skip everything but `name`, `version`, and `entry point`. You can use the default `index.js` for `entry point`. This file is where you set your package's exports:
```js
// my-package/index.js
exports.myPackageLog = function() {
console.log("logged from my-package");
};
```
Now apps that include this package can do:
```js
import { myPackageLog } from 'my-package';
myPackageLog(); // > "logged from my-package"
```
When choosing a name for your npm package, be sure to follow the [npm guidelines](https://docs.npmjs.com/files/package.json#name).
## ES Modules and CommonJS
Modern npm packages typically use ES Modules syntax. Here's how to set up your package for both ESM and CommonJS:
### ES Modules package
Create a `package.json` with `"type": "module"`:
```json
{
"name": "my-package",
"version": "1.0.0",
"type": "module",
"main": "index.js",
"exports": {
".": "./index.js"
}
}
```
Then use ES Module syntax in your code:
```js
// my-package/index.js
export function myPackageLog() {
console.log("logged from my-package");
}
export async function fetchData() {
// async operations work naturally
const result = await someAsyncOperation();
return result;
}
```
### Dual ESM/CommonJS package
To support both module systems, you can provide separate entry points:
```json
{
"name": "my-package",
"version": "1.0.0",
"main": "dist/cjs/index.js",
"module": "dist/esm/index.js",
"exports": {
".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}
}
}
```
## Including in your app
When you are developing a new npm package for your app, there are a couple methods for including the package in your app:
### Inside node_modules
Place the package in your app's `node_modules/` directory, and add the package to source control. Do this when you want everything in a single repository:
```bash
cd my-app/node_modules/
mkdir my-package
cd my-package/
meteor npm init
git add -f ./ # or use a git submodule
```
### Using npm link
Place the package outside your app's directory in a separate repository and use [`npm link`](https://docs.npmjs.com/cli/link). Do this when you want to use the package in multiple apps:
```bash
cd ~/
mkdir my-package
cd my-package/
meteor npm init
# Register the package globally
npm link
# Link it in your app
cd ~/my-app/
meteor npm link my-package
```
Other developers will also need to run the `npm link` command.
### Using npm workspaces
For monorepo setups, npm workspaces provide a cleaner solution:
```json
// root package.json
{
"name": "my-monorepo",
"workspaces": [
"packages/*",
"apps/*"
]
}
```
Then organize your packages:
```
my-monorepo/
├── package.json
├── packages/
│ └── my-package/
│ └── package.json
└── apps/
└── my-meteor-app/
└── package.json
```
After any method, edit the `dependencies` attribute of your app's `package.json`, adding `"my-package": "1.0.0"` (use the same version number you chose during `meteor npm init`).
## Writing Meteor-compatible packages
When writing npm packages that will be used in Meteor, keep these considerations in mind:
### Async/await patterns
Meteor 3 uses async/await throughout. Your package should follow the same patterns:
```js
// Good - async pattern
export async function getUserData(userId) {
const response = await fetch(`/api/users/${userId}`);
return response.json();
}
// Export both sync and async versions if needed
export function getUserDataSync(userId) {
// sync implementation for client-side use
}
export async function getUserDataAsync(userId) {
// async implementation
}
```
### Environment detection
Use Meteor's environment detection when available:
```js
export function doSomething() {
if (typeof Meteor !== 'undefined') {
// Running in Meteor
if (Meteor.isServer) {
// Server-side code
} else if (Meteor.isClient) {
// Client-side code
}
} else {
// Running outside Meteor (tests, Node.js, etc.)
}
}
```
### Isomorphic packages
For packages that work on both client and server:
```js
// utils.js - works everywhere
export function formatDate(date) {
return new Intl.DateTimeFormat('en-US').format(date);
}
// server.js - server only
export async function queryDatabase(query) {
// Database operations
}
// client.js - client only
export function showNotification(message) {
// UI notifications
}
```
Then set up conditional exports:
```json
{
"name": "my-isomorphic-package",
"exports": {
".": "./utils.js",
"./server": "./server.js",
"./client": "./client.js"
}
}
```
## Publishing your package
You can share your package with others by publishing it to the npm registry. While most packages are public, you can control who may view and use your package with [private modules](https://docs.npmjs.com/private-modules/intro).
### Public packages
To publish publicly:
1. Create an npm account at [npmjs.com](https://www.npmjs.com/)
2. Log in from the command line:
```bash
npm login
```
3. Publish your package:
```bash
npm publish
```
When you're done, anyone can add your package to their app with `npm install --save your-package`.
### Scoped packages
For organization packages, use scoped names:
```bash
npm init --scope=@myorg
npm publish --access public
```
Users install with:
```bash
npm install @myorg/my-package
```
### Development workflow
If you want to share packages during development, we recommend using `npm link` or workspaces instead of the registry. If you use the registry, then every time you change the package, you need to:
1. Increment the version number
2. Publish
3. Run `npm update my-package` inside your app
## Overriding packages with a local version
If you need to modify a package to do something that the published version doesn't do, you can edit a local version of the package on your computer.
Let's say you want to modify an npm package. First, install it if you haven't already:
```bash
meteor npm install --save some-package
```
Now the code has been downloaded to `node_modules/some-package/`. Add the directory to source control:
```bash
git add -f node_modules/some-package/
```
Now you can edit the package, commit, and push, and your teammates will get your version of the package.
To ensure that your package doesn't get overwritten during an `npm update`, change the default caret version range in your `package.json` to an exact version.
Before:
```json
"some-package": "^1.0.2",
```
After:
```json
"some-package": "1.0.2",
```
### Using a Git repository
An alternative method is maintaining a separate repository for the package and changing the `package.json` version to a git URL:
```json
{
"dependencies": {
"some-package": "git+https://github.com/yourusername/some-package.git#main"
}
}
```
Or use a specific commit:
```json
{
"dependencies": {
"some-package": "git+https://github.com/yourusername/some-package.git#abc1234"
}
}
```
Every time you edit the separate repo, you'll need to commit, push, and run `npm update some-package`.
## TypeScript support
To add TypeScript support to your npm package:
### Installing dependencies
```bash
npm install --save-dev typescript
```
### Configuration
Create a `tsconfig.json`:
```json
{
"compilerOptions": {
"target": "ES2020",
"module": "ESNext",
"moduleResolution": "node",
"declaration": true,
"declarationMap": true,
"outDir": "./dist",
"strict": true,
"esModuleInterop": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}
```
### Package.json setup
```json
{
"name": "my-typescript-package",
"version": "1.0.0",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"scripts": {
"build": "tsc",
"prepublishOnly": "npm run build"
}
}
```
### Source code
```typescript
// src/index.ts
export interface UserData {
id: string;
name: string;
email: string;
}
export async function fetchUser(id: string): Promise {
const response = await fetch(`/api/users/${id}`);
return response.json();
}
```
## Testing your package
Set up testing for your npm package:
### Jest configuration
```bash
npm install --save-dev jest @types/jest ts-jest
```
Create `jest.config.js`:
```js
module.exports = {
preset: 'ts-jest',
testEnvironment: 'node',
testMatch: ['**/*.test.ts'],
};
```
### Writing tests
```typescript
// src/index.test.ts
import { formatDate } from './index';
describe('formatDate', () => {
it('should format dates correctly', () => {
const date = new Date('2024-01-15');
expect(formatDate(date)).toMatch(/1\/15\/2024/);
});
});
```
### Package.json scripts
```json
{
"scripts": {
"test": "jest",
"test:watch": "jest --watch"
}
}
```
## Best practices
1. **Use semantic versioning** - Follow [semver](https://semver.org/) for version numbers.
2. **Include a README** - Document your package's API and usage.
3. **Add a LICENSE file** - Specify the license for your package.
4. **Use .npmignore** - Exclude development files from the published package.
5. **Test before publishing** - Run your test suite before every publish.
6. **Use lockfiles** - Commit `package-lock.json` for reproducible builds.
7. **Keep dependencies minimal** - Only include necessary dependencies.
8. **Support tree-shaking** - Use ES modules to enable tree-shaking in bundlers.
Meteor.logout()}>
{currentUser.username} 🚪
...
```
:::
Remember to style your username as well.
::: code-group
```css [client/main.css]
.user {
display: flex;
align-self: flex-end;
margin: 8px 16px 0;
font-weight: bold;
cursor: pointer;
}
```
:::
Phew! You have done quite a lot in this step. Authenticated the user, set the user in the tasks, and provided a way for the user to log out.
Your app should look like this:
In the next step, we are going to learn how to deploy your app!
---
---
url: /tutorials/svelte/6.filter-tasks.md
---
## 6: Filter tasks
In this step, you will filter your tasks by status and show the number of pending tasks.
### 6.1: Reactive State
First, you will add a button to show or hide the completed tasks from the list.
In Svelte, we can manage component state using reactive variables directly in the `
```
:::
Then, add the button in the markup to toggle the state:
::: code-group
```html [imports/ui/App.svelte]
-
{#if subIsReady}
{#each tasks as task (task._id)}
Loading ...
{/if}
You can also see all the messages that Meteor is sending and receiving from the server, this is useful for you to learn more about how Meteor works.
Install it in your Google Chrome browser using this [link](https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf).
### 6.5: Pending tasks
Update the App component in order to show the number of pending tasks in the app bar.
You should avoid adding zero to your app bar when there are no pending tasks. Use the reactive `incompleteDisplay` in the header:
::: code-group
```html [imports/ui/App.svelte]
In the next step we are going to include user access in your app.
---
---
url: /tutorials/svelte/5.styles.md
---
## 5: Styles
### 5.1: CSS
Our user interface up until this point has looked quite ugly. Let's add some basic styling which will serve as the foundation for a more professional looking app.
Replace the content of our `client/main.css` file with the one below, the idea is to have an app bar at the top, and a scrollable content including:
- form to add new tasks;
- list of tasks.
::: code-group
```css [client/main.css]
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
button {
font-weight: bold;
font-size: 1em;
border: none;
color: white;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
padding: 5px;
cursor: pointer;
}
button:focus {
outline: 0;
}
.app {
display: flex;
flex-direction: column;
height: 100vh;
}
.app-header {
flex-grow: 1;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.main {
display: flex;
flex-direction: column;
flex-grow: 1;
overflow: auto;
background: white;
}
.main::-webkit-scrollbar {
width: 0;
height: 0;
background: inherit;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
box-shadow: 0 3px 3px rgba(34, 25, 25, 0.4);
}
.app-bar {
display: flex;
justify-content: space-between;
}
.app-bar h1 {
font-size: 1.5em;
margin: 0;
display: inline-block;
margin-right: 1em;
}
.task-form {
display: flex;
margin: 16px;
}
.task-form > input {
flex-grow: 1;
box-sizing: border-box;
padding: 10px 6px;
background: transparent;
border: 1px solid #aaa;
width: 100%;
font-size: 1em;
margin-right: 16px;
}
.task-form > input:focus {
outline: 0;
}
.task-form > button {
min-width: 100px;
height: 95%;
background-color: #315481;
}
.tasks {
list-style-type: none;
padding-inline-start: 0;
padding-left: 16px;
padding-right: 16px;
margin-block-start: 0;
margin-block-end: 0;
}
.tasks > li {
display: flex;
padding: 16px;
border-bottom: #eee solid 1px;
align-items: center;
}
.tasks > li > label {
flex-grow: 1;
}
.tasks > li > button {
justify-self: flex-end;
background-color: #ff3046;
}
```
:::
> If you want to learn more about this stylesheet check this article about [Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/), and also this free [video tutorial](https://flexbox.io/) about it from [Wes Bos](https://twitter.com/wesbos).
>
> Flexbox is an excellent tool to distribute and align elements in your UI.
### 5.2: Applying styles
Now you need to add some elements around your components. You are going to add a `class` to your main `div` in the `App.svelte`, also a `header` element with a few `div` elements around your `h1`, and a main `div` around your form and list. Check below how it should be; pay attention to the name of the classes, they need to be the same as in the CSS file:
::: code-group
```html [imports/ui/App.svelte]
-
{#if subIsReady}
{#each tasks as task (task._id)}
Loading ...
{/if}
In the next step, we are going to make this task list more interactive, for example, providing a way to filter tasks.
---
---
url: /tutorials/svelte/4.update-and-remove.md
---
## 4: Update and Remove
Up until now, you have only inserted documents into our collection. Let's take a look at how you can update and remove them by interacting with the user interface.
### 4.1: Add Checkbox
First, you need to add a `checkbox` element to your `Task` component.
Next, let’s create a new file for our `task` template in `imports/ui/Task.svelte`, so we can start to separate the logic in our app.
::: code-group
```html [imports/ui/Task.svelte]
Todo List
-
{#if subIsReady}
{#each tasks as task (task._id)}
Loading ...
{/if}
If your computer is fast enough, it's possible that when it sets up the default tasks a few will have the same date. That will cause them to non-deterministically "jump around" in the UI as you toggle checkboxes and the UI reactively updates. To make it stable, you can add a secondary sort on the `_id` of the task:
::: code-group
```html [imports/ui/App.svelte]
```
:::
### 4.3: Remove tasks
You can remove tasks with just a few lines of code.
First, add a button after the `label` in your `Task` component and a `deleteTask` function between the `script` tags.
::: code-group
```html [imports/ui/Task.svelte]
### 4.4: Getting data in event handlers
In a collection, every inserted document has a unique `_id` field that can refer to that specific document. Inside the component, the `task` prop provides access to the task object, including its `_id`
and other fields like `isChecked` and `text`. We use these to call Meteor methods for updating or removing the specific task.
In the next step, we are going to improve the look of your app using CSS with Flexbox.
---
---
url: /tutorials/svelte/3.forms-and-events.md
---
## 3: Forms and Events
All apps need to allow the user to perform some sort of interaction with the data that is stored. In our case, the first type of interaction is to insert new tasks. Without it, our To-Do app wouldn't be very helpful.
One of the main ways in which a user can insert or edit data on a website is through forms. In most cases, it is a good idea to use the `
...
```
:::
Let's now add an `addTask()` function handler inside the script tags below the imports. It will call a Meteor method `tasks.insert` that isn't yet created but we'll soon make:
::: code-group
```html [imports/ui/App.svelte]
...
let newTask = '';
async function addTask(event) {
event.preventDefault();
if (newTask.trim()) {
await Meteor.callAsync("tasks.insert", {
text: newTask,
createdAt: new Date(),
});
newTask = '';
}
}
...
```
:::
Altogether, our file should look like:
::: code-group
```html [imports/ui/App.svelte]
Todo List
-
{#if subIsReady}
{#each tasks as task (task._id)}
- {task.text} {/each} {:else}
Loading ...
{/if}
In the next step, we are going to update your tasks state and provide a way for users to remove tasks.
---
---
url: /tutorials/svelte/2.collections.md
---
## 2: Collections
Meteor already sets up MongoDB for you. In order to use our database, we need to create a _collection_, which is where we will store our _documents_, in our case our `tasks`.
> You can read more about collections [here](/api/collections).
In this step we will implement all the necessary code to have a basic collection for our tasks up and running.
### 2.1: Create Tasks Collection
We can create a new collection to store our tasks by creating a new file at `imports/api/TasksCollection.js` which instantiates a new Mongo collection and exports it.
::: code-group
```js [imports/api/TasksCollection.js]
import { Mongo } from "meteor/mongo";
export const TasksCollection = new Mongo.Collection("tasks");
```
:::
Notice that we stored the file in the `imports/api` directory, which is a place to store API-related code, like publications and methods. You can name this folder as you want, this is just a choice.
If there is a `imports/api/links.js` file from the starter project, you can delete that now as we don't need it.
> You can read more about app structure and imports/exports [here](/tutorials/application-structure/).
### 2.2: Initialize Tasks Collection
For our collection to work, you need to import it in the server so it sets some plumbing up.
You can either use `import "/imports/api/TasksCollection"` or `import { TasksCollection } from "/imports/api/TasksCollection"` if you are going to use on the same file, but make sure it is imported.
Now it is easy to check if there is data or not in our collection, otherwise, we can insert some sample data easily as well.
You don't need to keep the old content of `server/main.js`.
::: code-group
```js [server/main.js]
import { Meteor } from "meteor/meteor";
import { TasksCollection } from "/imports/api/TasksCollection";
const insertTask = async (taskText) =>
await TasksCollection.insertAsync({ text: taskText });
Meteor.startup(async () => {
if (await TasksCollection.find().countAsync() === 0) {
[
"First Task",
"Second Task",
"Third Task",
"Fourth Task",
"Fifth Task",
"Sixth Task",
"Seventh Task",
].forEach(insertTask);
}
});
```
:::
So you are importing the `TasksCollection` and adding a few tasks to it iterating over an array of strings and for each string calling a function to insert this string as our `text` field in our `task` document.
### 2.3: Render Tasks Collection
Now comes the fun part, you will render the tasks with Svelte. That will be pretty simple.
In your `App.svelte` file, import the `TasksCollection` file and, instead of returning a static array, return the tasks saved in the database:
::: code-group
```html [imports/ui/App.svelte]
Todo List
-
{#if subIsReady}
{#each tasks as task (task._id)}
- {task.text} {/each} {:else}
Loading ...
{/if}
You can change your data on MongoDB in the server and your app will react and re-render for you.
You can connect to your MongoDB running `meteor mongo` in the terminal from your app folder or using a Mongo UI client, like [NoSQLBooster](https://nosqlbooster.com/downloads). Your embedded MongoDB is running in port `3001`.
See how to connect:
See your database:
You can double-click your collection to see the documents stored on it:
In the next step, we are going to create tasks using a form.
---
---
url: /tutorials/svelte/1.creating-the-app.md
---
## 1: Creating the app
### 1.1: Install Meteor
First, we need to install Meteor by following this [installation guide](https://docs.meteor.com/about/install.html).
### 1.2: Create Meteor Project
The easiest way to setup Meteor with Svelte is by using the command `meteor create` with the option `--svelte` and your project name:
```shell
meteor create --svelte simple-todos-svelte
```
Meteor will create all the necessary files for you. With `--svelte` option, Meteor generates a project using Svelte 5 and Rspack as the bundler, and this is the approach walked through in this tutorial. Using [the Rspack bundler](../../about/modern-build-stack/rspack-bundler-integration.md) is the default convention in Meteor 3.4+, as it improves dev speed, enables more build features, and provides better control over bundle size and configuration.
We provide the final app for both the Rspack and Meteor bundlers. This guide follows the Rspack version and reaches the same final state. The Meteor bundler version is for those who prefer the legacy bundler.
::: info
You can find the final version of this app on GitHub using the [Rspack bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-rspack) or the [Meteor bundler](https://github.com/meteor/meteor3-svelte/tree/3.4-meteor).
:::
The files located in the `client` directory are setting up your client side (web), you can see for example `client/main.html` where Meteor is rendering your App main component into the HTML.
Also, check the `server` directory where Meteor is setting up the server side (Node.js), you can see the `server/main.js` which would be a good place to initialize your MongoDB database with some data. You don't need to install MongoDB as Meteor provides an embedded version of it ready for you to use.
You can now run your Meteor app using:
```shell
meteor
```
Don't worry, Meteor will keep your app in sync with all your changes from now on.
Take a quick look at all the files created by Meteor, you don't need to understand them now but it's good to know where they are.
Your Svelte code will be located inside the `imports/ui` directory, and the `App.svelte` file will be the root component of your Svelte To-do app.
### 1.3: Create Tasks
To start working on our todo list app, let’s replace the code of the default starter app with the code below. From there, we’ll talk about what it does.
First, let’s simplify our HTML entry point like so:
::: code-group
```html [client/main.html]
Todo List
-
{#each tasks as task (task.text)}
- {task.text} {/each}
In Svelte with Meteor, your main entry point is `client/main.js`, which imports and mounts your root Svelte component `App.svelte` to a target element in the HTML like ``
Svelte components are defined in `.svelte` files, which can include `
```
```javascript [index.js]
/* global WebApp Assets */
import crypto from "crypto";
import express from "express";
const router = express.Router();
router.get("/", async function (req, res, next) {
const buf = await Assets.getTextAsync("index.html");
if (buf.length > 0) {
const eTag = crypto.createHash("md5").update(buf).digest("hex");
if (req.headers["if-none-match"] === eTag) {
res.writeHead(304, "Not Modified");
return res.end();
}
res.writeHead(200, {
ETag: eTag,
"Content-Type": "text/html",
});
return res.end(buf);
}
return res.end("Index page not found!");
});
WebApp.handlers.use(router);
```
:::
There are a couple things to think about with this approach.
We're reading the contents of index.html using the [Assets](../api/assets.md) module that makes it really easy to read files out of the _private_ root folder.
We're using the [connect-route](https://www.npmjs.com/package/connect-route) NPM package to simplify WebApp route processing. But you can use any package you want to understand what is being requested.
And finally, if you decide to use this technique you'll want to make sure you understand how conflicting client side routing will affect user experience.
### React SSR Optimization (Meteor 3.4)
**Experimental: Disable Boilerplate Response** ([PR#13855](https://github.com/meteor/meteor/pull/13855))
Meteor 3.4 introduces an experimental configuration option to improve React Server-Side Rendering (SSR) performance by disabling the default boilerplate HTML response.
When using React SSR with packages like `server-render`, you may want to completely control the HTML output without Meteor's default boilerplate injection. Enable this with:
```js
// server/main.js
import { WebApp } from 'meteor/webapp';
WebApp.addHtmlAttributeHook(() => ({
disableBoilerplateResponse: true
}));
```
**Benefits:**
- **Full SSR Control**: Complete control over the HTML output for SSR frameworks
- **Better Performance**: Reduces overhead by skipping boilerplate generation
- **Cleaner Output**: No automatic script/link injection, allowing custom placement
**Use Cases:**
- Advanced React SSR implementations
- Custom HTML structure requirements
- Integration with SSR frameworks like Next.js patterns in Meteor
**Important Notes:**
- This is an experimental feature and may change in future releases
- When enabled, you're responsible for including all necessary scripts and assets
- Best used with the `server-render` package for full SSR implementations
Example with server-render:
```js
import { onPageLoad } from 'meteor/server-render';
import { renderToString } from 'react-dom/server';
import { WebApp } from 'meteor/webapp';
WebApp.addHtmlAttributeHook(() => ({
disableBoilerplateResponse: true
}));
onPageLoad(sink => {
const html = renderToString(