For part 1: click here!

So after the long philosophy post about our team at Workpop, lets get into some nitty gritty technical frustrations.

1. Beware of refactoring templates

We’re all for refactoring to smaller components but in Meteor you can’t just refactor from the Spacebars point of view. We’ve had such a big problem of losing data contexts and events that we require our team to first understand what is going behind the scenes of a large template. You can’t have your new templates lack the helpers it needs or the events. Man…your users will be stranded. So watch that data context.

@SachaGrief recommended using HTML Comments outlining what goes in his templates.

2. Embrace “full stack”

Many of our team members are straight up engineers. But the reality is, since Meteor is “fullstack” and our users only care about what they see…CSS is still very important. Most know that the amount of people it takes to write scalable and maintainable css is 1. So if you have 10 engineers all working on features moving fast? Result: you end up with all css lines thrown below random sheets in random folders. This is frustrating if your features start crossing over and next thing you know you’re css is getting overwritten and you don’t know how to change it. Embrace CSS patterns, make it clean, get organized.

We’ll be releasing how we do CSS soon!

3. Don’t trust “this”

Now there are exceptions to this rule, but seeing as number 1 can happen, “this” can change. We use Template.instance(), that way you know exactly where you’re getting data from!

4. Don’t forget this.next()

Man this happened to us a lot until we decreed we’d slap someone in the face if it happened again…(just kidding ☺) Many times you put logic in beforeActions via Iron Router, well if you just do

} else {

return;

}

The route never gets dispatched.

5. Make sure your variables don’t throw exceptions

A good example is in our job types. Job Types are not a user entered field on our site. So some jobs may not even exist. And you cant have a jobtype without a job or an industry. But we had some code in a forEach statement utilizing:

var jobType = job.industry.jobType.

Well if that job didnt exsist that’d throw. If industry didnt exist that’d throw. And well your forEach is fucked.

Though tedious we do use this pattern:

var jobType = job && job.industry && job.industry.jobType

ChuckSmart from crater offered this piece of wisdom using CoffeeScript you can get around that pattern using:

jobType = job?.industry?.jobType

Our team uses JavaScript primarily, so we stick to our long hand approach.

Also, Richard Lai suggested:

Meteor has a super secret utility function Meteor._get() that will totally help with those annoying nested field checks.

if (Meteor._get(job, ‘industry’, ‘jobType’)) {}

6. Don’t let the user update fields you dont want them to update

You would think this is a no brainer but as you setup your schema you’ll be creating sub-objects and some may have important information, while other keys don’t. It iss super important that you whitelist your update methods with exactly what is allowed to be updated! We made the mistake of allowing users to update all of their meta info when we really only wanted them updating meta.roles

We’ll be releasing information on how we achieve this soon!

7. Throw meaningful errors.

Don’t write general Meteor Errors. We had this error when users were uploading resumes that threw “There was an unexpected error”….hmm that doesn’t help anyone. It turned out we were converting the resumes into images using the filepicker api which errored out cause you can only call “convert” on an image. Clearer errors means faster debugging. Also, with errors use Kadira. For ambiguous errors its the best so dive in and find out whats going on.

8. Choose your fields wisely!!

No need to send more than what you need over the wire.

9. Beware of Method callback soup

In a perfect world your methods will run super fast and the callbacks will run fast as well. But if your response time goes up and you’re sequencing your methods in a callback after callback…users are gonna be waiting around along time. We were experiencing this issue because we had some unindexed queries. Finds and updates were taking so long so our methods response time was so high. Man that sucked.

10. Analytics should be done at the data level not in event handlers.

So we had this analytics event called Application Read, whenever an application was read we fired this event from an event handler. See number 1, we eventually refactored and all of a sudden this event went dark. We realized if your UI changes its way too much effort to be keeping track of your events.

What we did to remedy this was to use Meteor’s handy dandy EJSON clones. Now for application read we check the key of read before an update is called and after the update was called. If there was a change in read, we trigger the event. Way better than keeping track of UI changes. The UI will change faster and more often. To keep track of analytics events in UI really was tiring.

We’ll be releasing how we do analytics soon!

Thats it! Send me some more tech frustrations you’ve run into!

Thanks

Abhi