Hi @SarathSantoshDamaraj, I’m not sure how well I can answer your questions directly but hopefully I can give you some pointers in the right direction. My React knowledge is all academic or theoretical so forgive me if anything doesn’t sound right.
First off, @NullVoxPopuli gave a talk at EmberConf last month comparing patterns between React and Ember (video here, slides here). Definitely worth a watch and might be helpful for some context.
From what I understand, some of the “component types” in React were conceived to deal with the fact that everything in React is a component, and that state management is generally (flux/redux/etc) managed in a different, somewhat segregated way. In Ember there are more constructs for dealing with state and application architecture so these component categories might not all be necessary or useful, at least in the sense that they would be in React.
For example in Ember we have the Router and Routes as first class primitives. A route is made up of a route js file, a corresponding template, and generally a controller. In React you might have one or more components that perform the same functions. In the classic Redux sense your route controller and template might replace the “Container” component that deals with data/state and render “Presentation” components which can be reused across the app/other apps. The route/controller “own” the model and then, in the data flow that we call “Data Down Actions Up” the route model (and controller state) and actions will be passed down to the presentation components, which will invoke the actions to mutate the data. This establishes a clear one-way data flow, not dissimilar to Flux architecture. In general I prefer to write a route template and wait to extract components until there is repetition or clear separation of concern between UI elements, but that’s just my 2c.
Another thing that can replace the need for some of the higher order or provider components is Ember’s “Service” construct. A service is a singleton that can contain properties, methods, etc. and can be injected into any component/controller. The Ember Data store is a service, and common addons like Ember Simple Auth use services as the primary way of sharing authentication state with the app. Because a service isn’t a component it doesn’t need to live in the component hierarchy, it can just be used when and where it is needed.
As far as I’m aware Ember Data is quite different from the way data management is typically done in the React ecosystem. Ember Data is concerned mainly with data from an API/backend/source of truth, and doesn’t concern itself with component state (which, from what I understand is different from Redux where your application state and “backend” data would all be in the same store, again though I’m not an authority on that). Data is typically loaded in the model hook of a route, and kept in the store. Each record is not just an instance of your a model but also a complex object with it’s own “state machine” more or less that tracks changes, saved/in-flight/unsaved status, etc. Ember Data is very powerful, and highly customizable. Anyway I guess the real point is that because it’s accessed via the store service and generally used in Routes, you don’t need extra stuff in your component hierarchy for data fetching either.
Oh and as for folder structure, one of (IMO) the great parts about Ember is that it follows strong conventions so you don’t have to worry too much about your source file tree structure. This “classic” layout will be changing fairly soon with what we call “Module Unification” which is a new default file structure, but the way the Ember currently organizes source is just in /app with subdirectories for templates, routes, components, helpers, etc. It’s possible to nest routes (there are rules of thumb about why/when you should do this) and also possible to have component directory trees but that is less common in my experience. So all that to say, you don’t need to worry all that much about your file structure, the app architecture (route hierarchy, good component design patterns) is much more important.
Hope some/all of that makes sense and is helpful. There might not be clear analogs between Ember and all of the React concepts, but there’s probably a tool that accomplishes the same thing. Maybe someone with more React experience can weigh in with a better comparison.
EDIT: oh and I think you’re definitely on the right track with your approach. Again I’m not a proponent of abstracting components out too soon, but YMMV. The best use-case for extracting a component from a route template is obviously a reusable piece of UI, but also any containers that will organize their own child components or that you want to render container elements. And of course any code/UI that fits together in a natural way. Leveraging services where appropriate can keep your component hierarchy nice and clean.
