Cytoscape.js arbor layout canvas renderer? - cytoscape.js

I searched here and found a reference to their being a canvas renderer, but have not found it as an option. Has that project been completed?
I am trying to render 200-300 nodes and roughly 600-1000 edges and am not seeing acceptable performance. I had initially been using sigma.js and was happy with the rendering, but the lack of documentation and small feature set pushed to use cytoscape.js...which I am loving for how easy it is to work with the styles and accessing node and edge attributes...

This question has been answered elsewhere, but I will reiterate for completeness. Please do not ask in more than one place in future. It will not make for faster answers, and it's confusing for others.
There is indeed a canvas renderer, and it is the only renderer available to you -- other than the trivial null renderer or a renderer you write yourself.
As for performance, it is a function of the layout performance and you're using one of the most expensive types of layouts -- forcedirected -- although nice for several graphs. If you want better performance given the size of your graph, you're better off using a nonsimulation layout, like the breadthfirst layout.
You also have the option of writing your own layout that could be completely tailoured to your dataset. It's very easy with the API: http://cytoscape.github.io/cytoscape.js/#extensions/layouts

Related

Vue: wait to render until all components are mounted

I have a Vue/Nuxt web app where pages are dynamically generated from lots of components that have child components.
The trouble is the header and footer are rendered first, then the child components that have the actual content. This looks terrible on first load and Lighthouse doesn't like it. It's an Avoid large layout shifts failure. For context it's only an issue when client side rendering, SSR would eliminate this issue while intoducing others.
What I could do is edit every single component in my project and add an event on mounted. That could then be used to decide when to show the layout. The problem is it would be a major hassle and would cause bugs when new components are added and this bit is forgotten.
I'm not able to find any general solution to this in Vue and/or Nuxt. I'd love to have a new lifetime hook of allMounted which would only fire when child components are also mounted but it doesn't exist. Even that would be a bit hacky. An even more general render when all components are mounted option would be awesome.
I'm not sure that a dynamic component can help in your case, but I guess that your company's website will not really benefit from this. Indeed, the problem of the content jumping will still be present IMO.
<component :is="currentTabComponent"></component>
I still think that you content is highly static IMO and that you could even switch to full static to have the best performance benefits rather than having to wait for a long time (TTFB) while SPA is loading all the content. It may be a bit more challenging to have everything look nice of course (before/after the hydration).
Also, you should have an idea of the approximate size of your containers. In that case, you could use some skeletons and a maybe even a prototyping font to visually populate the blocks.
In case you do not agree or think that this is not doable, you still have this solution to your disposal
<child-component #hook:mounted="makeSomeStuff"></child-component>
With this you may be able to display a full-sized loader until your content is done loading. You could add a mixin with the longer mounted syntax in each component to avoid too much boilerplate but this one is deprecated and do have various issues.
But IMO, the issue is more in your way of fetching the data (asyncData and fetch hooks are nice) and the way that everything is full dynamic when there is no specific need. If it's more important to keep the dynamic part, I guess that you can be serious on code reviews or plug some git hooks or alike to kinda scan the code and see if the required mounted emits are in place.
There is no ideal solution in your case but keep in mind that Lighthouse will always prefer some SSR content with the less amount of JS. Here is my personal bible to anything performance related, you could probably grasp some nice tips in this really in-depth article.
Update for Vue3
The syntax has changed for Vue3: https://v3-migration.vuejs.org/breaking-changes/vnode-lifecycle-events.html#_2-x-syntax

vue-chartjs - Do Experienced Vue Developers use this wrapper?

I am refactoring my first pass Vue dashboard application, which uses vue-chartjs to access chart.js.
As part of doing this, I am creating a set of wrapper components that encapsulate more functionality than just the chart itself, e.g. titles, dialogs, measures etc. In doing this, I am finding that how vue-chartjs adds complexity to my task for multiple reasons, e.g. the structure of renderChart props doesn't match the parameters of chartjs itself. Also, vue-chartjs has its own unique capabilities that add a layer of complexity to using chartjs.
I assume there are other complexities that are reduced by using vue-chartjs, but... my question is:
Do experienced Vue developers use vue-chartjs to access chart.js? Or do you go direct to chart.js? My first pass approach was derived from a tutorial, and I didn't question it at the time. Now that I'm doing more complex things, vue-chartjs is getting in my way as I try to simplify and minimize data marshaling.
For now I am working around these issues, but if it is reasonable to create my own wrappers rather than add an unnecessary level through vue-charts, I would like to try that. But I don't want to venture into this without first asking for feedback from other dashboard folks who have done it!
Thanks for any advice on this.
Anecdotally speaking, I've found in some code reviews less experienced devs tend to rely on vue-**** wrapper libraries even when there is little (or even no) benefit. Adding additional libraries increases exposure to more dependencies, each of which theoretically carries a potential for security vulnerability. I've also seen the opposite, where the functionality is re-invented when a vue library is available and would save significant amount of time and have a more robust component(like including aria fields or thoroughly tested with various browsers). The tl;dr; being, I take is on a case by case basis.
I agree with #Daniel. I can give another example where I used vue-popper wrapper package. The component itself is not bad, it's well done, however, it uses the previous major version of popper.js which lacks good new features and improvements. For this reason I created later my own implementation of vue popper with the latest version.

Reactive Extensions for .NET Developers

I found some information about this but I have several confusion regarding this. So when we need to use this RX.NET.
What are the important of using this items? When I need to use this?
As with every toolset, it can shape how you approach problems. Given a hammer, all your problems may become nails. It is the same with Rx.NET. It gives you a new approach. Whether you choose to use this approach for a particular problem is up to you, and as with any tool or technology, there are plusses and minuses. You will need to study and gain experience to make those sort of complex judgements for yourself.
For starters, Rx.NET allows you to cultivate the approach of programming 'reactively.' This is akin to functional programming, in the sense that you declare behavour as being composed of underlying behavior. Rx.NET allows you to specify functions over streams to give new streams. This powerful technique can be applied to almost any problem you can imagine.
For example, a program using Linq and Rx.NET to draw mouse movements as points on a screen within a bounding box would like something like:
mouseMovements.Where(box.Contains(m)).Subscribe(DrawPoint)
where mouseMovements would be your mouse event as an observable
You could declare the
myPointsInBox = mouseMovements.Where(box.Contains(m))
as its own observable and have multiple subscribers:
myPointsInBox.Subscribe(DrawPoint)
myPointsInBox.Subscribe(ConnectWithLines)
myPointsInBox.Subscribe(UpdatePointCounter)
you can make streams from streams
var everyThousandthPoint= myPointsInBox.Buffer(….).Select(…)
and then do things with them
everyThousandthPoint.Subscribe(FlashPointCounter)
You get the idea.

Access to previous steep Html

I am learning Elm and I seems that you make a new VirtualDOM every view "frame".
view : Model -> Html Msg
There is no reference to the previous generated Html value, so there is no option to update it (in a functional way). You must rebuild it from scratch. This is highly inefficient.
How can you reuse the old frame and only update changed nodes (and their ancestors)?
EDIT
As an answers points, Elm have Html.Lazy. With it and the clever runtime you can avoid repeating most of the work and data allocation (useless garbage collector pressure is a bad thing), but at the expenses of adding a lot of cognitive load on the programmer.
Reasoning about strictness/laziness on the term level (instead of on the type level) is error prone (see Haskell and seq).
The perfect solution would be a view function with this signature:
view : Model -> Html Msg -> Html Msg
This way you have access to the previous frame VirtualDOM and you can share as much of it with the new frame data structure as you want.
Is this option available? If not, why not?
As you know, Elm uses a "virtual DOM". Your program outputs lightweight objects that describe the DOM structure you want, and the virtual DOM implementation "diffs" the current and new structure, adding, modifying, and removing elements/attributes/properties as required.
Of course, there is a small performance penalty to using a virtual DOM over directly manipulating the DOM, but the difference doesn't matter in most web applications. If you find that your application has poor performance in the view function, there are several ways to improve performance, such as Html.Lazy
Many other popular libraries use a virtual DOM, such as React, Angular, and Vue. Usually, it's easier to render your application with a virtual DOM (rather than "manually" manipulating the DOM), so many of the popular frameworks implement one.

How can I custom limit the extent of an ArcGIS basemap?

I am writing web application based on ArcGIS API for javascript. So far I managed to create empty map using this tutorial and write some code which visualizes some data.
The basemaps which ArcGIS offer are quite nice and I would like to use them, but they represent whole world and what I need is basemap of just a single country. What's the best/easiest way to do it? I tried using ArcGIS Online to edit basemap but the don't offer good options for cutting single country.
I found some links out there but they aren't solving my problem (or my knowledge is to small to understand them), for example https://developers.arcgis.com/javascript/latest/sample-code/basemap-custom/index.html
If you like the look and feel of the Esri basemaps, you don't want to make your own. That's certainly technically possible, but requires a greater command of ArcMap and publishing services -- and isn't what you're really looking for. And basemap tiles shouldn't be edited, even ones you publish yourself, since the difficulty of doing that well is just not worth the effort.
Instead, you can restrict the JavaScript map to prevent panning outside your area of interest. Whenever the user moves to an extent that exceeds allowed values, the code automatically resets the extent to the allowed limit, and they can't move outside it. (You can similarly restrict zoom levels so they won't even be able to zoom out further than the view of your area of interest.)
For code details, see existing answers on Restricting base map on specific extent in ArcGIS API for JavaScript 3? (GIS.StackExchange)