How do you name your components?

react
1

I am just dipping my toe into react and am immediately facing a challenge which I am sure others have dealt with.

What format do you use for naming your react components??
Considering they are all global I don’t like the idea of using a component name like: Menu or Header - even though they seem like the most appropriate names.

Is there anything I should look out for?
Any useful tips or ideas I could try out?

3 Likes
2

I have a folder called “genericComponents” where i will put my<Table> <Select> <Button> and even <Autocomplete> components.
Outside of this folder, i put my more customized components <ProductsTable> <ProductsOrderTable> and containers <ProductsSearchContainer>
That’s all i know for now :smiley:

2 Likes
3

Not with modules. Check out meteor 1.3. If you’re just starting out, it’s a really bad choice not to learn, and get used to the es6 import/export syntax. That’s how nearly the entire React ecosystem outside of meteor does things. You’re going to end up using it one day, might as well be today.

But… if that’s not an option, then you’ve got to make use of the global namespace:

For example, put this code in the body of any file. As long as it’s run first, other files will be able top read (and write) the first two values.

EveryOneCanSeeMe = true;
this.sameThing = true
var otherfilesCantSeeMe = false;

Then you’ll want to have react components set themselves as members of a globally available object.

something.js

MyNamespace = {};

ComponentB.js

MyNamespace.Button = React.createClass({

  [...]

});

ComponentC.js


MyNamespace.FormInput = class extends React.Component {

  [...]

};

and finally, Layout.js


class Layout extends React.Component {

  [...]

  render() {
    return (
      <form>
         <MyNamespace.FormInput name="username" />
         <MyNamespace.FormInput name="password" type="password" />
         <MyNamespace.Button enabled={true} type="submit" label="Login" />
      </form>
    );
  }
}

###caveat:
something.js must be executed first for this to work otherwise you will get an error.
This is because of Meteor’s File Load Order, (modules fix this btw). So you’re going to want to google that. The work around is pretty easy, but ugly.

4

Since uppercase comes first, wouldn’t it be best to name the bootstrap file Something.js and the components componentA.js, componentB.js and componentC.js?

5

I tried namespacing, but it just seems annoying to work with. Had a nice bug today which took me a while to discover due to global namespace clutter.

Made a Pikaday-component based heavily on the code below.
Named the component Pikaday. Didn’t consider that the library used that name :wink:
Even something as simple as C.ComponentName would solve stuff like this.
Considering forking the repo and making a meteorpackage for pikaday. I see a lot of common components are missing from atmosphere…

6

I think that correct way these days with Meteor 1.3 would be to put your components to imports folder as mentioned here [SOLVED] Meteor 1.3 not strictly enforcing import/export?

And than import them as you need. I did not tried if classical cascading way works - but I think it should be better to mention all needed imports in every file so also testing can be done without executing additional files etc.

As opposed to hand them up on global namespace in 1 file. But if expect them on some namespace from before, it can enable you to migrate slowly instead of need to rewrite all dependencies for all the components etc at once.

I have not played with it yet, just observed some discussions.

7

I have some untested ideas, and opinions on this.

First, I actually decided I don’t like the idea of the Meteor 1.3 imports folder. Just make everything lazy loading, and let the developer decide where to import things. Except perhaps CSS.

React naming components: I used to structure my apps like this:

client
├── components
│   ├── DumbSpinner
│   │   ├── DumbSpinner.jsx
│   │   └── DumbSpinner.scss
│   ├── EditModal
│   │   ├── EditModal.jsx
│   │   └── EditModal.scss
│   ├── Greeter
│   │   └── Greeter.jsx
│   ├── IconButton
│   │   ├── IconButton.jsx
│   │   └── IconButton.scss
│   ├── Modal
│   │   ├── Modal.jsx
│   │   └── Modal.scss
│   ├── NewsPopup
│   │   ├── NewsPopup.jsx
│   │   └── NewsPopup.scss

That way every component is tucked away with its CSS. Though in some cases, it might be a good move to inline your styles. A few of us just had a great discussion about inline styles that you may want to read: Inline styles with React - thoughts?

Now with modules, I’m thinking of maybe changing up my structure a bit, and perhaps going for something like this:

client
└── components
    ├── blog
    │   ├── blog.jsx
    │   └── blog.scss
    └── user-account
        ├── user-account.jsx
        └── user-account.scss

And each JSX file has several React components that are related inside of it. Then I could do cool things like this, when I want to use these:

import {BlogList, BlogItem} from '../components/blog/blog.jsx';

I feel like with components broken down more into stateless components, you could wind up in file hell where you have a whole bunch of files that just have 8-12 lines of code in it, and I’m not sure if I like that kind of setup. I’m curious what other React users think of this idea.

Side note: I’ve seen some people just make folders for components, and name the code inside index.jsx. I personally don’t like this, because if I have 6 tabs open, they’re all labeled “index.jsx” and I can’t tell what’s what.

1 Like