[Solved] I seem to be duplicating code fairly often, is there an equivalent to ASP user controls?


#1

So in a past life I did a bit of C# / ASP development, I’ve been using meteor for a couple months now (loving it of course) and I’m starting to find that I’m duplicating code faily often. I don’t really care if there is something exactly like how ASP handles user controls, but it was faily convenient to be able a to write chunk of code/asp, then easily include it any other page by referencing the control.

I’m really just looking to see if there there’s a better way to what I’m doing and user controls came to mind… For example I might have a few screens that needs to have the same chunk of customer of account information embeded somewhere that need to be reactive to the rest of the page. That chunk of customer info will be the exact same on 4 screens, as of the moment, I’m putting the same customer view logic on each page. Any thoughts?


#2

Using generic templates in my applications is how I keep code duplication low. I have a route where I can create a mongo document and I have a separate route where I can edit that document. I have two templates, “edit” and “create”, and then I have a third template that is “manipulate.” I keep all or the logic for both edit and create inside the manipulate template. I don’t know if that makes any sense or not.

Essentially treating templates as partials is the way that I keep client side code duplication low.


#3

Thanks for the reply, it does make sense. Are your templates duplicated in each page that has those common functions, something were your basically copying the same template from page to page. I do similar with the cust/acct info, just a pain when I need to make changes, it has to be done in each page, with a certain project I’m working on I see that problem getting worse… Not that it can’t be dealt with, would be nice to change it in one place instead.

It’d be awesome (or not, I haven’t really thought it through :slight_smile: ) to write a single stand alone template and somehow link it into pages where I want it to show up. There’s be extra stuff in dealing with the db subscriptions probably, but seems like it’d be helpful.


#4

You should only have to write template specific functions once. Basically you could have a template look like this.

<template name="foo">
    {{>bar}}
</template>
<template name="baz">
    {{>bar}}
</template>

<template name="bar">
  The number 2 is {{isEven 2}}
  The number 3 is {{isEven 3}}
</template>

Then you can have a template foo that would have common functions.

Template.bar.helpers({
   isEven:function(number) {
    return number%2==0 ? "even" : "odd";
  }
})

Now anywhere where you throw {{>bar}} the helper isEven is available. You can even keep them in separate folders. It doesn’t matter.

I’m not really sure if I have answered your question so if you have a more specific problem you would like me to help you address please feel free to ask. I can take a look at your code or if you outline the problem I can try to help you to the best of my ability.


#5

Wow, I’m an idiot, quick, bury this thread! lol

I never realized that individual templates could be broken out into their own files and used multiple times… That’s exactly what I was after… Thanks khamoud!


#6

@johnf, if you didn’t realize this then I’m sure others were also confused so questions like this help everyone. :wink:

In addition to sub-templates themselves, you can also cut down on duplicate code by creating global helpers that can be used in any template. isEven from @khamoud’s example would be a good candidate.

You may find it helpful to look through the meteor examples that can be created from the command line. leaderboard is fairly simple, todos is more complex.

$ meteor create --example leaderboard
$ meteor create --example todos

#7

hahaha I know how you feel.
I’ve had plenty moments like these.


#8

React fans would still say Meteor has “weak templating and its APIs aren’t object-oriented”.

One step farther from templating is using packages extensively. Here’s a good presentation on aiming to place as much code as possible into packages, in order to increase modularity, testability and reusability.