Afraid of becoming a components addict

1

Hi, in the last weeks I’ve mastered the art of component creation to a very high level. Such a level that I’ve become a dangerous developer :smiley: . I feel the urge to make components for everything.

The underlying truth is that components are very easy to manage, but my Ember experience is very short, so I’m not sure of what I am doing.

For example: I have a very big Product table, but i don’t want a gigantic Input/Edit page.

  • I want the “Show Product page” to be built using different pieces or modules, visually separated.

  • The Input/Edit forms are small modals that pop from each one of the “modules” in the main “Show Product page” (prices, multimedia, texts, comments, history, etc.)

OPTION1:

My initial approach (coming from a “procedural world”), was creating a big "Show Product template, with all the fields. My modules should be just visual pieces separated by HTML/CSS structures. The only components should be the modal forms to edit data.

OPTION2:

But now I am the master of components! I can also build my thematic modules as Ember components, with enclosed "show "and “edit” functions. The edit forms should be nested components inside each module. This way, the Product template will be just a clean and schematic container with calls to load components.

To follow the DDAU paradigm, the final “save” to persist data should be in the Product Controller, using clossures down to the nested forms. I think it’s easier if each module can save data, but I prefer playing by the common rules.

MY DOUBTS

Theese components will not be reused anywhere in the application. And reusing things is one of the main reasons for all the component theory. Thats what I’ve read, isn’t it? In this case, components are just an organizational tool.

When things go bigger, I do not know if my components addiction will be a problem somehow. For example, with the components directory growing and growing exponentially.

I like the idea of “ambitious web applications”, that’s why I’m here. :slight_smile: There is a lot to learn before that, but I am ambitious from day one, and I will greatly appreciate some real world advice until I can make my own decisions.

Regards: Nacho B.

1 Like
2

I think option2 is fine. Some components naturally get reused in many places, but others don’t, and that’s fine.

Your scenario is very common, which is one reason that the module unification design has local lookup (the ability to nest local components inside a folder where they’re used).

3

Thank you, Edward!

I tried the two options yesterday, intensively and extensively, and option 2, thinking in “modules”, gives me more structure and flexibility. It creates some issues, but I think I will resolve them.

As you said, "Some components naturally get reused in many places, but others don’t. The keyword here is “naturally”. I’m gonna try not to force the component way, but I can use it with confidence.

The RFC is very interesting. It seems that Modularity goes beyond the mere directory structure.

I don’t like the Pods as a whole system, but the current system with some “modular” intelligence should be great.

Regards:

Nacho B.

1 Like