Package Only Using Mediator Pattern

[alfreema]

I am very new to meteor and like the idea of creating packages to get good code reuse and separation. I am trying to learn how to create my own packages and find the meteor documentation a little lacking for newbs like myself (mainly because there isn’t a super simple example where I can wrap my head around the entry points).

I did stumble upon this one year old blog entry and think it’s a great concept: http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator-pattern

My questions are:

1. Has this been solved by a robust package of some sort?

2. Wouldn’t the Mediator object itself best be stored in its own package that is included in any apps wishing to use it?

3. Could someone point me to a super simple, but current, bare bones example of how to write local packages?

Thanks!

[Sanjo]

3. Could someone point me to a super simple, but current, bare bones example of how writing local packages?

You can create a new local package with meteor create --package my-package (my-package is the name).

[alfreema]

Thanks for the feedback Sanjo.

The tutorial docs are good enough to get me through the “setup” steps. I’ll list them here in case I screwed anything up. Let’s say I want to call my package “alerter” and all I want it to do is alert(‘here’) when called.

meteor create app
cd app
mkdir packages
cd packages
meteor create --package alfreema:alerter
cd …
meteor add alfreema:alerter
meteor list

alfreema:alerter  0.0.1+
autopublish          1.0.3  Publish the entire database to all clients
insecure             1.0.3  Allow all database writes by default
meteor-platform      1.2.2  Include a standard set of Meteor packages in...

So I can get through the setup just fine. The problem comes at this point … how do I wire up the app and alerter in JSP?

To test this I just want to modify the default app created by meteor such that when the person clicks the button, it calls my Alerter package to cause an alert(‘here’) to be called.

So I change this:

'click button': function () {
      // increment the counter when button is clicked
      Session.set('counter', Session.get('counter') + 1);
    }

to this

'click button': function () {
      // increment the counter when button is clicked
      Session.set('counter', Session.get('counter') + 1);
      Alerter.throwAlert();
    }

Then in my packages/alerter/alerter.js, I add this:

var Alerter;

Alerter = {
  throwAlert: function() {
    alert('alert thrown');
    console.log('alert thrown');
  }
};

And this is where I am stuck. I don’t understand how to wire ‘app’ up with ‘alerter’ such that when I click the button, alerter’s throwAlert method gets called. Is there some super simple documentation out there that explains this step?

[Sanjo]

I think you look for api.export('Alerter', 'client') (docs). Also check out the rest of the package.js docs.

[alfreema]

Ok, I think api.export has done the trick!

I still wonder if there is a robust package out there that solves the Mediator Pattern problem?

[luisherranz]

@alfreema

I still wonder if there is a robust package out there that solves the Mediator Pattern problem?

That Mediator pattern is very similar to the Flux Dispatcher, which a replacement of MVC made by Facebook.

The view is only allowed to emit events. Then, the logic to update the model is not on the view, but in other places, called “Stores”. They register a callback for that event and do the appropriate changes to the model. Finally, the Views re-render with the updated model (which is pretty simple in Meteor thanks to reactivity).

In that blog post, myModule is a Flux View, Mediator is the Flux Dispatcher and Notify is a Flux Store.

This post explains the whys and whos of Flux:
http://blog.andrewray.me/flux-for-stupid-people/
But skip the re-render part, in Meteor you don’t need that.

If you are interested I have been studying how to combine Meteor and Flux and documented in this thread:

MeteorFlux Flow

Hi there everyone! I am about to start coding a project in Meteor and I want to use some kind of architecture. I want something very simple, but which won’t become a nightmare in the future. I took a quick look at Flux and I loved it. I have coded in the past using PureMVC so I am familiar with that kind of “notification centred” MVC framework. But what I used to hate about PureMVC is that you have to write a lot of boilerplate code here and there, which sometimes is not only time consuming b…

[warehouseman]

3. Could someone point me to a super simple, but current, bare bones example of how to write local packages?

About a month ago I published a bare-bones example on AtmosphereJS and GitHub : Dead simple demo if you are trying to get started with Meteor packaging. I suspect you have already grown past what it has to offer, but you might gather something useful from it.

I am now trying something more ambitious: to duplicate the functionality of the “Try Meteor” To Do List tutorial, but entirely within a package! I have no idea if it is even possible, but I’ll be asking a lot of questions here, and so perhaps you and I can trade insights and learn together. The end result ought to be useful to anyone else trying to go down this path. I’ll post a link to my initial GitHub project, when I’ve got it to a point where I won’t embarrass myself.

Please let me know, +ve or -ve whether the Fliptext thing helped at all.

[alfreema]

Outstanding! This is exactly what I was looking for. I was, like you, able to beat through some out-of-date blog posts to eventually get something working, but I have no clue how to use Tiny Test, and there will be some additional learnings when I get into your code.

Two thoughts about your post:

1. What is Travis CI?

2. On your https://github.com/warehouseman/fliptext/blob/master/README.md page, you have two misspellings for “internal”. Search for “intenal” and you will find them.

I can’t wait to pull this down tomorrow when I have time and really take a peak under the hood.

[alfreema]

That Mediator pattern is very similar to the Flux Dispatcher, which a replacement of MVC made by Facebook.

This post explains the whys and whos of Flux:
http://blog.andrewray.me/flux-for-stupid-people/
But skip the re-render part, in Meteor you don’t need that.

This is the exact type of feedback regarding architecture I was hoping for. I plan on spending some time reading up on Flow and see if it’s the right architecture decision for my needs. Thanks!

[warehouseman]

Aaron,

I am absurdly pleased that my demo can be of use to you. I had one of those “a tree falls in the forest” moments when I announced it here. Thanks so much for looking it over.

1. What is Travis CI?

It’s GitHub’s automated software test bed. Look at the warehouseman:fliptext listing on AtmosphereJS. Click on the black and green badge, then click on the “Build History” tab. Every time I committed fliptext, Travis grabbed it, built it with Meteor, NodeJS, etc, and then ran all my tests. If you go down the list you’ll see red commits. In my case, my first and only build failure so far was due to the Meteor build script for Travis getting one step behind the changes in Travis itself. Hah! That was freaky. It seems Meteor testing and Meteor packaging are still very bleeding edge.

2. On your https://github.com/warehouseman/fliptext/blob/master/README.md page, you have two misspellings for “internal”. Search for “intenal” and you will find them.

Thanks! Fixed. (and re-tested, by Travis, just now).

You might be interested in my question on here from me this morning : “Try Meteor” as a package. Snag #1. Can a package export a template? .

My goal is to define my packages in such a way that they appear in a menu with no further effort than just referring to them in .meteor/packages.

Martin

[jktr]

Regarding a really easy way to create packages within a meteor project, just today I came across this youtube video explaining the package Package Kitchen. I did not yet try the package myself, but the video looked quite promising.

[alfreema]

Wow, now that’s interesting. I could see where that’s super handy when developing.

[Sanjo]

I have no clue how to use Tiny Test

You can also use sanjo:jasmine for package testing

[warehouseman]

At first blush Package Kitchen looks really useful, but I have my own boilerplate package with slightly different needs. Filling its blanks is easier than filling the blanks of Package Kitchen and then tweaking the result to meet those needs.

[schonne]

I’m actually working on 4 large projects all using a similar meteor code base. I decided to use a package-only approach to make it easier to build all 4 projects at the same time. I have to say that the package-only approach is by far the best way to structure a Meteor app. It keeps features contained making it easier to maintain and test. My structure is basically this:

PUBLIC: contains public assets like style sheets, images, logos specific to that project.
PACKAGES: contains each separate package
CONFIG: contains two files - a config.js which contains two JSON objects: Client and Server that I attach project-specific properties that the packages will reference. This keeps the packages generic and agnostic from the project. The other file is a routes.js file (I use flow-router).

That’s it.

The packages are designed to be generic - like something I’d push up to Atmosphere. The packages have no project-specific styling because I have specific packages for each theme for the 4 projects that I pull in on a per-project basis.

I develop the packages in a minimal environment, usually with only a blank Meteor app and only the packages that the new package will be dependent. This ensures that the package is kept agnostic. When it’s done, I write a README file describing how it works. This makes it so I can re-use it on multiple projects indefinitely - just like an Atmosphere package - except these packages work specifically how I need them to.