Feature request: make *client*.js files run on client, *server*.js files on server

1

My directory structure goes like this:

Folder Dog
    dog.html
        template <name="dog">    
    dog.js
    dog.css

I then further nest them.

This way, I have all the files I need (and often edit together) in one logical unit, which simplifies my navigation. Rarely, I have two templates per file, but that’s more of an exception and usually when the templates are “private”.

Is this a good practice?

The problem I have with it is, now I have a bunch of

if (Meteor.isClient) and if(Meteor.isServer).

That among other things means that my server code gets sent to the client, right? Not very good from security standpoint, even if it’s not executed on the client.

A more secure alternative I think would be to have a directory structure like this:

Folder Dog
    dog.html
        template <name="dog">    
    folder client
        dogClient.js
        dog.css
   folder server
       dogServer.js

However, that’s way too many folders for just 3 or 4 tiny files, an extra mouse click to expand and collapse them, and waste of IDE screen space if they are already expanded.

If my use case makes any sense at all, would it be logical to allow “client” and “server” in file names, not just in directory names? Or even something reserved, like $server, in order to account to files like “sendToServer.js”.

Am I making any sense? Or is my use case way off?

Edit: alternatively, how about parsing the .js files to make sure the if(Meteor.isServer) clauses don’t get sent to the client?

1 Like
2

Why are you not using the client / server folder system?

2 Likes
3

Because that would involve one of the two

  1. creating dozens of client & server folders, as per my example, or

  2. twice the amount of navigation, switching back and forth between the large client and server folders (am I the only one bothered by it?)

In my example, I want to put all Dog-related stuff together. Why would not I?

4

You only need one of each client and server folder. You can also create subfolders of the client and server to organize things of you believe you will have many files.

5

I like client / server folder system. It would be great to add another folder Cordova (-:

6

To be fair, it might involve more switching of directories, but in my opinion thats the easiest way. I havent had any problems so far, even with larger applications.
One more question: why would you need dozens of client/Server folders? You only need one for the client and one for the server.

7

Imho Meteor doesn’t need less folders but more, like the ability to put package in folders.
A flat structure is good for small apps, but nothing more.

8

+1
I would love to have “myCollection.helpers.js”, “myCollection.helpers.client.js” and “myCollection.helpers.server.js” in the same folder, without the need for Meteor.isXXX() and its extra indent.

9

What’s wrong with:

./modules/
  dog/
    client/
      dog.html
      dog.js
      subscriptions.js
    common/
      methods.js
      collections.js
    server/
      publications.js
10

Clarity of a single folder over 3 folders with one file each. The 2 approaches are complementary, depending on your module size.

11

Sure, I can have (abandoning the Dog metaphor)

client
   libarary
   location
   librarian
   customer
   book
   transaction
   hold
   etc

And then the same structure on server, and maybe on Cordova. But that’s a lot of switching between client and server, and if your goal is to be as isomorphic as possible, then why keep client and server logically more separate than they need to be? IMHO, they belong together: you’ve modified book.client.html a bit, you’ve modified book.server.html a bit, you’ve modified book.cordova.html a bit and maybe book.css, done. One logical unit. Object-oriented of sorts. If that’s how you are thinking, then the directory structure should accomodate IMHO.

13

With one folder per template, and those being grouped into larger folders, I would not call my folder structure flat. I am OK with folders with 2 or 3 files in each (that’s what I am having now, with a bunch of

  if Meteor.isClient()

I am less comfortable with creating dozens of one-file folders whose sole purpose of existence is to tag one very tiny .js file with just a few lines of code as something that lives on client or server.

To me, a folder is something intended to have more than one file in it.

14

I agree with @aaabbbccc I think if “client” and “server” are worth being special folder names with special meanings, then by the same token, perhaps 'server-" or “client-” in front of a filename could have that same special meaning… then this would be flexible for people who want to take advantage of a convention like that, but not actually use folders.

I think adding “special filenames” (for those who wish to use them) is not a big step from the already present “special folder names” (for those who wish to use them)

15

I don’t understand why you don’t put every code for the server under one server folder, and everything for the client under one client folder ?

17

I totally agree that it would be nice to be able to do this. Right now it isn’t possible but hopefully the file structure options will be improved in the future - it’s something we are aware of.

18

You should also add:

some-feature/
  some-feature.css
  some-feature.html
  client/
    some-feature.client.js
  server/
    some-feature.server.js
  lib/
    some-feature.shared.js

Which is also a useful structure when writing packages.

19

@sashko, actually this is possible )

I wrote smart package that allows to make filename rules for serving files to client/server or both.
I guess I should bring this package to atmosphere so everyone could use it.

20

@robfallows,

yes, it will work, but it’s not very convenient to have a lot of subfolders

21

How did you do that? Perhaps you could share the change with me? Or at least give me a general idea?

22

Because you can only have one of the two: either you group your files together by client/server first and by what they do second; or the other way around. I vaguely recall Meteor in its tutorial advocates both approaches, as both approaches have merits. If you do choose the latter (e…g. you are thinking in terms of domain concepts like libraries and books more than in terms of clients and servers, then what I am saying starts making sense. Otherwise, what’s your proposed way to implement the second approach without having a gazillion of one-file folders?

I think one-file folders are evil, that’s all.