Components
Since the tables, graphs, and any other form of visualization we're using are using the same data, and the Component contains the data, wouldn't it be redundant to create a plant-graph-component, a plant-table-component, etc.? Not sure if I'm understanding this part properly, but based off of that I would think we should just have a single Plant-Component for the actual visualization part, and then different components for searching and other things.

from aguaclara.github.io.

Actually, based off of the following information in the Angular tutorial, I think I may be thinking about it wrong:

The HeroDetailComponent is a different component than the HeroListComponent you've been reviewing. The HeroDetailComponent (code not shown) presents facts about a particular hero, the hero that the user selects from the list presented by the HeroListComponent.

So applying that to our case, maybe the plant-table-component would represent raw data about the plants while the plant-graph-component would represent a visually appealing graph version of that same data?

from aguaclara.github.io.

I agree with what Sneha said originally about storing the plant data into a single plant-data-component as opposed to having different plant-graph, plant-table, etc. components. Because isn't the transformation of the plant data into graphs and tables really just the result of different data visualization services acting on the same data component? Even in the HeroDetailComponent vs. HeroListComponent example that Sneha cited, it seems that the distinction was only needed as a result of the two components holding different data (e.g. the HeroListComponent just held a list of hero names whereas the HeroDetailComponent actually held more detailed information about each individual hero).
If this is indeed the case, then I think it would make more sense to have a single PlantDataComponent for each plant and then have different services such as TableVisualizationService, GraphVisualizationService, and even a service that formats it properly before being downloaded. This seems advantageous because we can keep the data for one plant all in a single central component without having to worry about the various other data components.
However, on the other hand, I see how this approach could be disadvantageous in the sense that any time one wants to visualize data, one would have to call a particular service whereas having multiple components would eliminate the need for the repeated work done by the services. I am not too familiar with how services in Angular work, but if it is costly or time consuming to repeatedly use a service then I think the multiple components approach would be better. However, if this is not an issue, I think the single component/multiple services approach might make more sense.

from aguaclara.github.io.

Current Website Architecture

Components

• Plant Component: One plant component that, depending on the selected plant, uses the Data Service to pull a plant's data and display.
• App Component: Responds to the selection of a plant in the navigation Template by interacting with the Plant Component so that it calls the corresponding getData method from the Data Service; houses the Plant Component.

Templates

• Graph Template
• Table Template
• Downloads Template
• Tabs Template (top of the page)
• Navigation Template : Responds to the selection of a plant by triggering the App Component to interact with the Plant Component as mentioned before

Services

• Data Service: Contains all the getData methods for each plant to be injected into the Plant Component
• Download Service

Thoughts

This is what we have come up with so far for the site. The main issue we are dealing with is that it seems like the Plant Component is doing a lot of work by handling all the data, so any ideas on how to break it up or redistribute the work would be great.

from aguaclara.github.io.

Hi all,

This sounds like the right idea. There are certainly some things that could be done to split the monolithic 'PlantDataService' into more than just one service. First off, you could split it into 'PlantMetaData' and PlantReportData' where the metadata pulls all the things that stay constant over time about a particular plant, like the number of filters, construction date, community, waterboard, etc... This way when you are serving something that just discusses the plants themselves without information about the actual data streaming in, you can include just that. Perhaps there needs to also be a service for each type of form. For instance, right now we only have the COLLECT form, but very soon we will be adding a chlorine dosing form and a small plant form. Seems like those could all have a 1 to 1 correspondence to the services we choose to build. The plant component should contain data visualization components. At least that's what it looks like from reading this. I think you should draw this out visually. Try drawing it in a Google Drawing and then sharing it with me! 😄

from aguaclara.github.io.

This now has it's own repo, post.visualize.angular Issues for that repo are tracked there.

from aguaclara.github.io.