Svelte + Tailwind + Meteor

Messing around:

• curl https://install.meteor.com/ | sh (only needed one time to install meteor)
• npm install (install dependencies)
• then just run npm run dev which starts tailwind JIT watcher and meteor together.

Notes for running

• 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
• Can interact with the backend-server (i.e. executing methods, performing db reads/writes) using meteor shell in another terminal after npm run dev
• Same idea with meteor mongo to launch mongodb cli/shell
• You can wipe all databases using meteor reset after shutting down the server. This will reset app data to a fresh clone.

Project organization explanation

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

1. Don't really need to mess with this as it's generated by the starter scaffold. main.{html, js} and output.css is generated by tailwind (even during development).
2. 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 a DBNAMEPublications.js for the publication code and DBNAMEMethods.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 use Meteor.call('someServerMethod', args) and someServerMethod should do the actualy database writing
3. 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.
4. This houses all the front-end code and operates just like a regular svelte app project. File-names and folder structure is totally flexible
5. 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.
6. 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