Messing around: After npm install
just run npm run dev
which starts tailwind JIT watcher and meteor together.
Note: if it's your first time installing meteor
, you will likely see a meteor: command not found
error message upon running npm run dev
. curl https://install.meteor.com/ | sh
worked for me over the standard npm install -g meteor
command.
- There are only 2 user accounts. So just use a private window or alternate browser to login as both:
- U:
meteorite
P:password
- U:
ejolly
P:test
- U:
- Can interact with the backend-server (i.e. executing methods, performing db reads/writes) using
meteor shell
in another terminal afternpm run dev
- Same idea with
meteor mongo
to launch mongodb cli/shell
originally created from meteor svelte scaffold
├── client (1)
│ ├── main.html
│ ├── main.js
│ └── output.css
├── imports
│ ├── api (2)
│ │ ├── messagesMethods.js
│ │ ├── messagesPublications.js
│ │ ├── userMethods.js
│ │ └── userPublications.js
│ ├── db (3)
│ │ └── MessagesCollection.js
│ └── ui (4)
│ ├── App.svelte (5)
│ ├── LoginForm.svelte
│ ├── chatui
│ │ ├── ChatUI.svelte
│ │ ├── Input.svelte
│ │ ├── Message.svelte
│ │ ├── MessageList.svelte
│ │ └── ProfileHeader.svelte
│ └── main.css
├── package-lock.json
├── package.json
├── server
│ └── main.js (6)
└── tailwind.config.js
- Don't really need to mess with this as it's generated by the starter scaffold.
main.{html, js}
andoutput.css
is generated by tailwind (even during development). - This is where you decide what databases to publish to the clients, so that when they run a
db.find()
even with no filters/queries it restricts the results they get. The convention from the scaffold is aDBNAMEPublications.js
for the publication code andDBNAMEMethods.js
for defining server-side methods to interact with that database. Can probably just put both in a single file to keep things simpler. We need server-side methods because clients can never write to any database directly. They must always useMeteor.call('someServerMethod', args)
andsomeServerMethod
should do the actualy database writing - This is the place a new database collection is created. Convention is one file per collection, but can also just use a single file. Currently just a collection to hold all messages.
- This houses all the front-end code and operates just like a regular svelte app project. File-names and folder structure is totally flexible
- This is the parent-most component that renders everything. The simplest app can run with just this file. For more complex projects or to manage different UIs (e.g.
chatui
in this project) it can be helpful to split things up and organize them as needed. But everything needs to eventually get imported into this component so it can run. - This file is kinda like an
express.js
server file, except you never need to actually create the server. Really it's for all the stuff that needs to happen before or alongside server startup. For example:- seeding an empty database with some data
- setting up a bunch of user accounts (e.g. admin account)
- running some one-time computations and saving the results