I am making a master-detail-detail application in React and GraphQL. Let me explain, there is a sidebar which shows products, and then when you click one of the list of products, ANOTHER list is shown in the main window (Master Detail). Here is the kicker, if you click one of the products in the Main window ANOTHER section on the right sidebar is populated with details. So like this:
Master List --> Details List --> Properties of Detail
I have React Router set up nicely and wondering what is the proper way to fetch? There are many ideas about this. For instance, should I structure the call and data for GraphQL to just fetch EVERYTHING onLoad? i.e. Parents (products), Children (product list), and details (details of children. Just fetch everything and setState?
OR, is the proper way to do things using GraphQL, to load ONLY the product list when the application loads, and when a user clicks on a product THEN FETCH the list of children, and when they click a child product, THEN fetch the details.
Just wondering about methodology.... of course when the lists get big, you would have a spinner show in the main pane, and then a spinner show in the details pane I suppose.
GraphQL solves the overFetching situation.... but, should I divide the fetch up when a user clicks and progressively fetch...or fetch everything at once and just click -> map() over the results.
I am curious to hear everyone's take on this.
The answer here is to not fetch the entire JSON tree at once. That would be a huge overfetch. We can create separate collections in MongoDB for the parent items and the child items in a one-to-many relationship, then use GraphQL to fetch exactly what we need in each window onClick/onChange. This seems the most efficient and expedient way since I am dealing with upwards of 10 panes of data and around 50 components. This is a very complex application I am working on.
Related
I'm building an app with vue-router and trying to achieve a UI similar to that of (the now defunct) Google Inbox. Or the Techcrunch homepage, which is possibly a better rendition of what I need.
there's a list of items
when you click on one of those items, it "expands in place" to display more details.
the URL also updates to reflect the expanded item
when clicking "back" the item collapses back into the list
when accessing the URL directly, the page should display the expanded item, and (optionally) could display more list items below.
Thing is, I can't figure out how I would build this - I'm trying to start from the idea of child routes, but I don't know where to place the child <router-view> since its location will always be dynamic based on which item was just clicked in order to expand.
I have a hunch it's related to named views but I can't wrap my head around it.
Any ideas welcome!
A similar topic came up on the Vue github page a while back, but involving the opening of modals as opposed to opening collapsing containers. One of the contributors to that thread wrote a pretty good blog post that might point you to a solution.
Once you get the dynamic routing sorted as they did above for modals, swapping the blurb for the article and animating the expansion should be fairly simple. The Vue docs cookbook has a good article on building a dynamic blog that should come in handy as well.
I have a calculated model with survey responses from Google Form and Directory information for each of the submissions. This model filters the results so as to return only the LATEST submission, where users have submitted multiple times.
I'm using an Accordion widget to display this info and I would like from the Details panel to create a popup that will display ALL of the responses for the Selected User in the Accordion.
Current Accordion UI
What's the best way to return only the values associated with the opened accordion card - see screenshot? e.g. John Doe's previous answers
Popup outcome
I tried using the bindings but I always get ALL the results for ALL the users in the same order as the Accordion and when I select a row it also selects the accordion row.
Any advice on how to approach this would be greatly appreciated.
TLDR You definitely need two different datasources (maybe even models), since you cannot reuse the same datasource for different widgets.
App Maker's datacource concept is different from classic ajax request. With classic XMLHttpRequest you can populated multiple result sets and use them wherever you want whereas adjusting query filters and reloading datasource with App Maker will just update items collection and rerender all widgets bound to the datasource.
Disclaimer: very ember newbie here so maybe what I'm asking is too basic but I don't find any explanation for this in the web
I have a parent object Report which contains a collection of Chart objects.
When I load the URL /api/reports/001/charts, the report 001 is requested to the API, then all the charts belonging to this report, then everything is rendered and .. seconds latter the page is shown to the User.
Like this:
What I'm trying is to offer a more progressive rendering:
The report is loaded from the API
The report is shown to the User with the chart elements with a loading spinner
Every chart is requested to the API individually
Every chart is show to the User individually
Steps 3 and 4 happen in parallel independent for each chart.
Something like this:
Of course I don't want anyone to come to me with a full solution, I'm looking more for orientation or maybe some link to where I can find inspiration.
We are doing something similar to this on our dashboard. In the route we load the users dashboard which contains a list of widgets and their position. Then in the dashboard template we render components for each widget, something like this.
{{#each widgets as |widget|}}
{{component widget.type widget}}
{{/each}}
Then by passing the widget instance (which has it's own custom settings) to the component we can then fetch the relevant data and display it. Each widget can also have it's own "spinner" to tell the user that it's still loading.
If I assume that your case is a bit simpler since you are only showing charts and probably by an id of some sort you could probably get away without using the component-helper and directly referencing your chart component.
{{#each charts as |chart|}}
{{report-chart chart.id}}
{{/each}}
I'm wondering what the best way is to handle a list of items and displaying an item detail when a user clicks/selects one of the items. An example of this would be showing a list of email messages in the left sidebar and showing the message details in the main content area when a user clicks on one of the messages.
Using #pangrantz's great answer on how to mark active menu item using router infrastructure I was able to come up with a working example: jsFiddle
But there are a couple things that don't seem quite right:
First, in #connectOutlets in the Router's show state, I'm setting the selected message on the controller as well as connecting the outlet with the same object. I would think I could do one or the other.
connectOutlets: function(router, context) {
router.set('messagesController.selected', context);
router.get('applicationController').connectOutlet('message-details', 'messageDetails', context);
}
Second, I'm transitioning to the same state from both the index and show states. I'm not even sure I want to be transitioning to a new state - I just want to hook up the outlet.
showDetails: Ember.Route.transitionTo('show')
Is there anything I can change to make this code more idiomatic? Thanks!
This code looks pretty idiomatic to my eyes. You are right, you do not need to set the selected message. When you connect the outlet for message details it will set the selected message as content on the message details controller.
You should IMO be transitioning from a index to a show state as this is good RESTful practice and also allows users to bookmark individual messages. I would make the URL to the index state be '/messages' rather than '/'.
What's a good way to organize views? Let's say I have a div that will contain a view from an admin panel perspective of users - there will be a list of users along with options to choose how many to display at a time, sorting options, what page to be on, filters, etc...
Would I want an outside view that contained everything except the table and data? And then an inside view that contains the table (along with the data)? And would the pagination have it's own view? And how would the pagination view use the click event to update the user view? I'm just confused on how to organize the views while still being able to have different events trigger other views to render() / collections to fetch().
So a basic hierarchy would look like:
- User View
- Table
- List of Users
- Pagination
- List of available numbers to click
- Filters
- Possible filters to apply to the data
Yet clicking a filter or number in the pagination should be able to get the collection to fetch() new data and refresh the view;
I second dogenpunk. I would have one User Collection / View. Because the whole hierarchy you describe above is about that one User Collection. All functions of it manipulate that collection and then you rerender the User View.
You could have a second User View, one single User, tied to a Model if you want to apply changes to the server for that user only.
I try to reflect my server-side MVC structure as much as I can.
Everything that can be put into a plugin, I do so, and then I keep those plugins in a separate location to the controllers which call the plugins. So in your case, the table view for the list of users would be held either in a table plugin, or possibly in the 'users' module if it was code I was really only going to use once.
If I need to override the output of the plugin, then I store the view inside the module folder.
What I try to avoid doing is storing views purely by the type of HTML inside them, so I wouldn't store a module's view as 'table' because that will get confusing if later it changes to a list. Obviously, if I have a 'table' plugin then the view for that is going to be a table, but then changing the JavaScript view means just changing the plugin call from 'table' to 'list' anyway.
My 2 cents to your original question. If you really want to make it a MV*, a pagination would be a view, your table would be a view. And have your collection to send out ( trigger ) events to change your view. And another questions I would ask myself also is what will be affected when my collection changes? For example, in your case, I don't think the collection changes will affect your userView directly, it only affects the Table and Pagination.