Ember, rendering a nested collection of models asynchronously - javascript

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}}

Related

Progressive fetch or all at once Master Detail

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.

Google Inbox-style navigation with vue-router

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.

server based bokeh plot update

I am using bokeh to embed a chart into an html template served by flask. I am using the autoload server method which returns a script which is then embedded into the html by the template renderer.
What I would like to do next is update the plot via a ajax type request, via a button click on hte same page, without necessarily having to replace the whole script which came along the first time the page loaded. It seems like it should be possible to just update the plot id or something similar so that the chart changes but without the brute force of replacing the whole script each time. Is this possible and how would it be done?
Thanks!
Hi this is currently possible, but difficult. We are currently working on a PR:
https://github.com/ContinuumIO/bokeh/pull/1274
that will be merged in the next few days (today's date: 2014.10.19) that will make things easier. It adds a "Bokeh.index" that contains all the top level objects, so that you can reach in and grab the data sources more easily and update them. Then there is a follow on PR to create an example just like you describe:
https://github.com/ContinuumIO/bokeh/pull/911
It may be a few weeks before I have time to finish that one, I would suggest subscribing to the issue on GH so you can be updated when it is ready.

living web page elements

I have a simple rails app with a model Task, which has 10 rows. It does not matter what's inside this table. On the index page I can see all 10 elements and I need to arrange them in proper sequence, when I did this, I should see a message "Done".
If I understand correctly this should be implemented in javascript, because page should not be reloaded, right?
I want to be able to rearrange the elements via drag and drop.
How I can realize that function?
I would start with here -> http://jqueryui.com/demos/sortable/
You can sort and its quite simple as there great examples on the site how to do this and hook into events.

backbone.js - views within views and managing events

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.

Categories