Comments (6)
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.
Related Issues (20)
- Style guide HOT 1
- Redesign time series layout HOT 2
- Implement plant efficiency visualizations HOT 2
- Incorporate Sass HOT 1
- Implementing a new feature that removes extreme outliers
- Noticed that we're getting bad data! HOT 3
- Displaying both 1 L/s data and main plant data on same graph HOT 2
- Filtered Water Turbidities from filterless plants are displayed as NaN values (dynamically apply plant parameter restrictions) HOT 1
- Optimize for mobile
- view backwash data HOT 1
- view messages sent by operators HOT 1
- Find and implement MVC framework HOT 2
- Selection of Plant to display new Plotly Graph
- Display all four data types for the graph HOT 1
- Create Two Graphs HOT 1
- Fix style and layout of second graph
- Understand how to incorporate table component
- Fix clr-tab html tag
- make x-axis on graph in Spanish.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aguaclara.github.io.