Google News
logo
Meteor.js Interview Questions
Meteor is a full-stack JavaScript platform for developing modern web and mobile applications (iOS, Android and Windows). Meteor includes a key set of technologies for building connected-client reactive applications, a build tool, and a curated set of packages from the Node.js and general JavaScript community.
 
* Meteor allows you to develop in one language, JavaScript, in all environments: application server, web browser, and mobile device.
 
* Meteor uses data on the wire, meaning the server sends data, not HTML, and the client renders it.
 
* Meteor embraces the ecosystem, bringing the best parts of the extremely active JavaScript community to you in a careful and considered way.
 
* Meteor provides full stack reactivity, allowing your UI to seamlessly reflect the true state of the world with minimal development effort.
Meteor is a full-stack JavaScript App Platform that assembles all the pieces you need to build modern web, desktop, and mobile apps with a single JavaScript codebase. React and Vue.js are JavaScript UI frameworks that can be used in conjunction with Meteor. Think of React, Vue.js, Svelte and Blaze as the 'V' in MVC. Meteor automatically manages the data flow between cloud and client applications, as well as client UI state and rendering regardless of which UI framework you use. You can also use Meteor with GraphQL or REST if you prefer.
Any database with a Node.js driver is supported by Meteor as we are a Node.js application on the server. MongoDB is usually the most used in Meteor community as it has more integrations with Meteor as well as a subscriptions model implemented on top of it.
You can get involved with Meteor’s community in a number of ways. Some of these include reporting bugs, triaging issues, or maintaining a community package. If you have any questions or would like to chat with like-minded developers, we recommend you check out our Slack community, Meteor Forums or GitHub. In these channels, you'll be able to collaborate with developers, learn best practices and even answer questions yourself.
In Meteor, it is also simple and straightforward to use the import syntax to load npm packages on the client or server and access the package’s exported symbols as you would with any other module. You can also import from Meteor Atmosphere packages, but the import path must be prefixed with meteor/ to avoid conflict with the npm package namespace. For example, to import moment from npm and HTTP from Atmosphere:

import moment from 'moment';          // default import from npm
import { HTTP } from 'meteor/http';   // named import from Atmosphere​
Web and mobile : Meteor provide platform for developing Android, IOS and Web apps.

Packages : Meteor support huge number of packages that are easy to install and use.

Universal Apps : The same code is used for mobile device and web browser.

Meteor Galaxy : Meteor offers Meteor Galaxy Cloud service for app development.
Hot code pushes are loaded by client devices, e.g. phones, in the background while the app continues to run. Once the new code has been fully loaded, the device is able to switch over to the new code quickly. This reduces or in some cases entirely eliminates the need to update code via the App Store and Google Play.
In Meteor, import statements compile to CommonJS require syntax. However, as a convention we encourage you to use import.
 
With that said, in some situations you may need to call out to require directly. One notable example is when requiring client or server-only code from a common file. As imports must be at the top-level scope, you may not place them within an  if  statement, so you’ll need to write code like:
if (Meteor.isClient) {
  require('./client-only-file.js');
}
Note that dynamic calls to require() (where the name being required can change at runtime) cannot be analyzed correctly and may result in broken client bundles.
 
If you need to require from an ES2015 module with a default export, you can grab the export with require("package").default.
CoffeeScript has been a first-class supported language since Meteor’s early days. Even though today we recommend ES2015, we still intend to support CoffeeScript fully.
 
As of CoffeeScript 1.11.0, CoffeeScript supports import and export statements natively. Make sure you are using the latest version of the CoffeeScript package in your project to get this support. New projects created today will get this version with meteor add coffeescript. Make sure you don’t forget to include the ecmascript and modules packages : meteor add ecmascript. (The modules package is implied by ecmascript.)
 
CoffeeScript import syntax is nearly identical to the ES2015 syntax you see above :
import { Meteor } from 'meteor/meteor'
import SimpleSchema from 'simpl-schema'
import { Lists } from './lists.coffee'
You can also use traditional CommonJS syntax with CoffeeScript.
Use in your application package.json file the section meteor.
 
This is available since Meteor 1.7
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    }
  }
}
When specified, these entry points will define in which files Meteor is going to start the evaluation process for each architecture (client and server).
 
This way Meteor is not going to eager load any other js files.
 
There is also an architecture for the legacy client, which is useful if you want to load polyfills or other code for old browsers before importing the main module for the modern client.
 
In addition to meteor.mainModule, the meteor section of package.json may also specify meteor.testModule to control which test modules are loaded by meteor test or meteor test --full-app:
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": "tests.js"
  }
}
If your client and server test files are different, you can expand the testModule configuration using the same syntax as mainModule:
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": {
      "client": "client/tests.js",
      "server": "server/tests.js"
    }
  }
}
The same test module will be loaded whether or not you use the --full-app option.
 
Any tests that need to detect --full-app should check Meteor.isAppTest.
 
The module(s) specified by meteor.testModule can import other test modules at runtime, so you can still distribute test files across your codebase; just make sure you import the ones you want to run.
 
To disable eager loading of modules on a given architecture, simply provide a mainModule value of false:
{
  "meteor": {
    "mainModule": {
      "client": false,
      "server": "server/main.js"
    }
  }
}
If you are a package author, in addition to putting api.use('modules') or api.use('ecmascript') in the Package.onUse section of your package.js file, you can also use a new API called api.mainModule to specify the main entry point for your package :
Package.describe({
  name: 'my-modular-package'
});

Npm.depends({
  moment: '2.10.6'
});

Package.onUse((api) => {
  api.use('modules');
  api.mainModule('server.js', 'server');
  api.mainModule('client.js', 'client');
  api.export('Foo');
});
Now server.js and client.js can import other files from the package source directory, even if those files have not been added using the api.addFiles function.
 
When you use api.mainModule, the exports of the main module are exposed globally as Package['my-modular-package'], along with any symbols exported by api.export, and thus become available to any code that imports the package. In other words, the main module gets to decide what value of Foo will be exported by api.export, as well as providing other properties that can be explicitly imported from the package:
// In an application that uses 'my-modular-package':
import { Foo as ExplicitFoo, bar } from 'meteor/my-modular-package';
console.log(Foo); // Auto-imported because of `api.export`.
console.log(ExplicitFoo); // Explicitly imported, but identical to `Foo`.
console.log(bar); // Exported by server.js or client.js, but not auto-imported.
Note that the import is from 'meteor/my-modular-package', not from 'my-modular-package'. Meteor package identifier strings must include the prefix meteor/... to disambiguate them from npm packages.
 
Finally, since this package is using the new modules package, and the package Npm.depends on the “moment” npm package, modules within the package can import moment from 'moment' on both the client and the server. This is great news, because previous versions of Meteor allowed npm imports only on the server, via Npm.require.
Packages can also specify a lazy main module:
Package.onUse(function (api) {
  api.mainModule("client.js", "client", { lazy: true });
});
This means the client.js module will not be evaluated during app startup unless/until another module imports it, and will not even be included in the client bundle if no importing code is found.
 
To import a method named exportedPackageMethod, simply :
import { exportedPackageMethod } from "meteor/<package name>";
Note : Packages with lazy main modules cannot use api.export to export global symbols to other packages/apps. Also, prior to Meteor 1.4.4.2 it is neccessary to explicitly name the file containing the module: import "meteor/<package name>/client.js".
These rules could become frustrating when one file depended on a variable defined by another file, particularly when the first file was evaluated after the second file.
 
Thanks to modules, any load-order dependency you might imagine can be resolved by adding an import statement. So if a.js loads before b.js because of their file names, but a.js needs something defined by b.js, then a.js can simply import that value from b.js:
// a.js
import { bThing } from './b';
console.log(bThing, 'in a.js');
// b.js
export var bThing = 'a thing defined in b.js';
console.log(bThing, 'in b.js');
Sometimes a module doesn’t actually need to import anything from another module, but you still want to be sure the other module gets evaluated first. In such situations, you can use an even simpler import syntax:
// c.js
import './a';
console.log('in c.js');
No matter which of these modules is imported first, the order of the console.log calls will always be :
console.log(bThing, 'in b.js');
console.log(bThing, 'in a.js');
console.log('in c.js');
For backwards compatibility Meteor 1.3 still provides Meteor’s global namespacing for the Meteor core package as well as for other Meteor packages you include in your application. You can also still directly call functions such as Meteor.publish, as in previous versions of Meteor, without first importing them. However, it is recommended best practice that you first load all the Meteor “pseudo-globals” using the import { Name } from 'meteor/package' syntax before using them. For instance :
 
import { Meteor } from 'meteor/meteor';
import { EJSON } from 'meteor/ejson';
You may combine both eager evaluation and lazy loading using import in a single app. Any import statements are evaluated in the order they are listed in a file when that file is loaded and evaluated using these rules.
 
There are several load order rules. They are applied sequentially to all applicable files in the application, in the priority given below:
 
1. HTML template files are always loaded before everything else
2. Files beginning with main. are loaded last
3. Files inside any lib/ directory are loaded next
4. Files with deeper paths are loaded next
5. Files are then loaded in alphabetical order of the entire path
  nav.html
  main.html
  client/lib/methods.js
  client/lib/styles.js
  lib/feature/styles.js
  lib/collections.js
  client/feature-y.js
  feature-x.js
  client/main.js​

 

For example, the files above are arranged in the correct load order. main.html is loaded second because HTML templates are always loaded first, even if it begins with main., since rule 1 has priority over rule 2. However, it will be loaded after nav.html because rule 2 has priority over rule 5.
 
client/lib/styles.js and lib/feature/styles.js have identical load order up to rule 4; however, since client comes before lib alphabetically, it will be loaded first.
By default, any JavaScript files in your Meteor application folder are bundled and loaded on both the client and the server. However, the names of the files and directories inside your project can affect their load order, where they are loaded, and some other characteristics. Here is a list of file and directory names that are treated specially by Meteor:
 
* imports : Any directory named imports/ is not loaded anywhere and files must be imported using import.
 
* node_modules : Any directory named node_modules/ is not loaded anywhere. node.js packages installed into node_modules directories must be imported using import or by using Npm.depends in package.js.
 
* client : Any directory named client/ is not loaded on the server. Similar to wrapping your code in if (Meteor.isClient) { ... }. All files loaded on the client are automatically concatenated and minified when in production mode. In development mode, JavaScript and CSS files are not minified, to make debugging easier. CSS files are still combined into a single file for consistency between production and development, because changing the CSS file’s URL affects how URLs in it are processed.
 
HTML files in a Meteor application are treated quite a bit differently from a server-side framework. Meteor scans all the HTML files in your directory for three top-level elements: <head>, <body>, and <template>. The head and body sections are separately concatenated into a single head and body, which are transmitted to the client on initial page load.
 
* server : Any directory named server/ is not loaded on the client. Similar to wrapping your code in if (Meteor.isServer) { ... }, except the client never even receives the code. Any sensitive code that you don’t want served to the client, such as code containing passwords or authentication mechanisms, should be kept in the server/ directory.
 
Meteor gathers all your JavaScript files, excluding anything under the client, public, and private subdirectories, and loads them into a Node.js server instance. In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node.
 
* public : All files inside a top-level directory called public/ are served as-is to the client. When referencing these assets, do not include public/ in the URL, write the URL as if they were all in the top level. For example, reference public/bg.png as <img src='/bg.png' />. This is the best place for favicon.ico, robots.txt, and similar files.
 
* private : All files inside a top-level directory called private/ are only accessible from server code and can be loaded via the Assets API. This can be used for private data files and any files that are in your project directory that you don’t want to be accessible from the outside.
 
* client/compatibility : This folder is for compatibility with JavaScript libraries that rely on variables declared with var at the top level being exported as globals. Files in this directory are executed without being wrapped in a new variable scope. These files are executed before other client-side JavaScript files.
 
It is recommended to use npm for 3rd party JavaScript libraries and use import to control when files are loaded.
 
* tests : Any directory named tests/ is not loaded anywhere. Use this for any test code you want to run using a test runner outside of Meteor’s built-in test tools.
 
The following directories are also not loaded as part of your app code :
 
* Files/directories whose names start with a dot, like .meteor and .git
* packages/ : Used for local packages
* cordova-build-override/ : Used for advanced mobile build customizations
* programs : For legacy reasons
* Meteor apps are by default real time. The data in the templates automatically gets updated, as soon as changes to the data are made.

* Coding is very simple and beginner friendly.

* The development process is highly simplified as frontend, backend and database all uses one language i.e. JavaScript.
* Meteor is not very much suitable for large and complex application.

* The Meteor API is rapidly changing, so each new version may bring breaking changes.

* Due to newer in industry there are not as many hosting services available for Meteor apps yet (Meteor 1.0 version).
Meteor template uses three important tags. These are head, body and template. Head and body tag has same function as in regular HTML, but template tag is used to connect HTML to JavaScript.
<head>  
   <title> </title>  
</head>  
 <body>      
</body>  
 <template name = "">   
</template>
EJSON is an extension of JSON syntax that supports Date and Binary types. The date and binary can be deserialize using the parse method.

For example :
if (Meteor.isClient) {  
   var ejsonDate = '{"$date": 1455029631493}';  
   var myDate = EJSON.parse(ejsonDate);  
   console.log(myDate);  
}
Meteor provides its own server (free) to deploy and test your application with command "meteor deploy appname". If you want to deploy application on your own server and domain, you will need VPS (Virtual Private Server) or cloud hosting like Heroku or Modulus.
Tracker is a small library that is used for auto update templates once the session data has changed. Tracker.autorun() method is used for tracking on session.
var data = 0  
   Session.set('sessionData', data);  
   Tracker.autorun(function () {  
      var sessionValue = Session.get('sessionData');  
      console.log(sessionValue)  
   });  

   Template.myTemplate.events({  
      'click #myButton': function() {  
         Session.set('sessionData', data++);  
      }  
   });
Session is used to save data while app is in use. The session data will be deleted while user leaves the app. In Meteor session are created by using Session.set() method. Once the session data is set, it can return using Session.get() method.
Using Fibers we can modify an asynchronous function, to write synchronous like code.In Meteor server-side code, the first-class support means that Meteor Promises play nicely with Fibers/Futures, which makes it possible to mix the sync-style coding we’ve become used to with the more mainstream Promise-based coding.
Blaze is Meteor's built-in reactive rendering library for creating user interfaces by writing reactive HTML templates. It eliminates the need for all the “update logic” in your app that listens for data changes and manipulates the DOM.
Meteor 2.7 introduce the new accounts-2fa package, support for TailwindCSS 3.x, and built-in support for PostCSS in standard-minifier-css. 
 
The above being said, there are a few items that you should do to have the latest CSS minifier in your project.
 
Update meteor-node-stubs : As we added support for node: imports, you need to update meteor-node-stubs to version 1.2.1:
meteor npm install meteor-node-stubs@1.2.1
Support for PostCSS
Starting from this version of Meteor (and 1.8.0 of standard-minifier-css), Meteor will run PostCSS plugins if you have them configured. If you are using juliancwirko:postcss as your css minifier, it is recommended to migrate to using standard-minifier-css. For most apps, this will only requiring switching which minifier the app uses:
meteor remove juliancwirko:postcss
meteor add standard-minifier-css
There are two differences with juliancwirko:postcss :
 
* The excludedPackages PostCSS option was renamed to excludedMeteorPackages
* Files with the .import.css extension are not treated specially

Note : In beta.1 of Meteor 2.7 we had added a new core package minifier-css-postcss but later decided to unify everything inside standard-minifier-css. So you shouldn’t use minifier-css-postcss.
 
TailwindCSS 3.x : Improvements in Meteor 2.7 enables minifiers to support TailwindCSS 3.x. These minifiers have been updated and tested with TailwindCSS 3:
 
* juliancwirko:postcss, starting with version 2.1.0
* standard-minifier-css

If updating from an older version of TailwindCSS to version 3, please read the Tailwind Official migration guide to make sure you had applied the changes required by TailwindCSS itself.
 
Accounts 2FA : accounts-2fa is a new package that enables two-factor authentication for accounts-password and accounts-passwordless.
 
There are no required changes to your application in any case, but if you want to provide 2FA for your users, and you are already using accounts-password or accounts-passwordless you can start using the new functions provided from 2FA package.
At its core, a web application offers its users a view into, and a way to modify, a persistent set of data. Whether managing a list of todos, or ordering a car to pick you up, you are interacting with a permanent but constantly changing data layer.
 
In Meteor, that data layer is typically stored in MongoDB. A set of related data in MongoDB is referred to as a “collection”. In Meteor you access MongoDB through collections, making them the primary persistence mechanism for your app data.

Server-side collections : When you create a collection on the server:
Todos = new Mongo.Collection('todos');
You are creating a collection within MongoDB, and an interface to that collection to be used on the server. It’s a fairly straightforward layer on top of the underlying Node MongoDB driver, but with a synchronous API:
// This line won't complete until the insert is done
Todos.insert({_id: 'my-todo'});
// So this line will return something
const todo = Todos.findOne({_id: 'my-todo'});
// Look ma, no callbacks!
console.log(todo);
Client-side collections : On the client, when you write the same line:
Todos = new Mongo.Collection('todos');
It does something totally different!
 
On the client, there is no direct connection to the MongoDB database, and in fact a synchronous API to it is not possible (nor probably what you want). Instead, on the client, a collection is a client side cache of the database. This is achieved thanks to the Minimongo library—an in-memory, all JS, implementation of the MongoDB API.
// This line is changing an in-memory Minimongo data structure
Todos.insert({_id: 'my-todo'});
// And this line is querying it
const todo = Todos.findOne({_id: 'my-todo'});
// So this happens right away!
console.log(todo);
The way that you move data from the server (and MongoDB-backed) collection into the client (in-memory) collection is the subject of the data loading article. Generally speaking, you subscribe to a publication, which pushes data from the server to the client. Usually, you can assume that the client contains an up-to-date copy of some subset of the full MongoDB collection.
 
To write data back to the server, you use a Method, the subject of the methods article.
 
Local collections : There is a third way to use a collection in Meteor. On the client or server, if you create a collection in one of these two ways:
SelectedTodos = new Mongo.Collection(null);
SelectedTodos = new Mongo.Collection('selectedtodos', {connection: null});
This creates a local collection. This is a Minimongo collection that has no database connection (ordinarily a collection would either be directly connected to the database on the server, or via a subscription on the client).
 
A local collection is a convenient way to use the full power of the Minimongo library for in-memory storage.
Now we can attach helpers to documents, we can define a helper that fetches related documents
Lists.helpers({
  todos() {
    return Todos.find({listId: this._id}, {sort: {createdAt: -1}});
  }
});
Now we can find all the todos for a list :
const list = Lists.findOne();
console.log(`The first list has ${list.todos().count()} todos`);
We can use the dburles:collection-helpers package to easily attach such methods (or “helpers”) to documents. For instance:
Lists.helpers({
  // A list is considered to be private if it has a userId set
  isPrivate() {
    return !!this.userId;
  }
});
Once we’ve attached this helper to the Lists collection, every time we fetch a list from the database (on the client or server), it will have a .isPrivate() function available :
const list = Lists.findOne();
if (list.isPrivate()) {
  console.log('The first list is private!');
}
On the client, Session provides a global object that may be used to hold an arbitrary set of key-value pairs. It can be used to save information such as the currently chosen item in a list. When the user exits the app, the data will be removed.
 
Syntax :
Session.set(key, value);
Run the following command in your terminal to add Session to your application :
meteor add session
Creating Meteor Application And Importing Module :
 
Step 1 : Create a React application using the following command.
meteor create foldername
Step 2 : After creating your project folder i.e. foldername, move to it using the following command.
cd foldername
Step 3 : Import Session module from ‘meteor/session’
import { Session } from 'meteor/session'

Step to Run Application : Run the application from the root directory of the project, using the following command.

meteor


Example : This is the basic example that shows how to use the Sessions component.

Main.html :

<head>
    <title>FreeTimeLearn</title>
</head>
 <body>
    <div>
        {{> employee}}
    </div>
</body>
<template name="employee">
    <h1 class="heading">FreeTimeLearn</h1>
    <p>
        Session provides a global object that may
        be used to hold an arbitrary set of key-value pairs.
    </p>
</template>

Main.js :

import { Session } from 'meteor/session';
import './main.html';
var emp = {
    FirstName: "John",
    LastName: "Smith",
    Age: 10,
    Designation: "System Architecture"
}
Session.set('data', emp);
var display = Session.get('data');
console.log(display);

Output : 
Meteor

Source : meteor