I have some custom NoFlo components and graphs in a NoFlo node.js-based project that I'd like to be able to use in the NoFlo UI.
In the NoFlo UI, I'm able to search for and use the custom components without a problem, but the graphs aren't appearing in the component search.
I looked for examples in the existing NoFlo library projects. Here are a couple examples of library projects that contain both custom components and graphs. I installed both into my project, and in both cases I'm able to see the components, but not the graphs in the NoFlo UI:
noflo-adapters
noflo-yaml
Should I be able to use these graphs as components in the UI? Do I need to expose them some other way?
Support for this was added quite recently. Can you ensure you're running noflo-nodejs 0.0.5 or newer?
Related
Kontext
Vue 3 provides a way to create "Custom-Elements": https://vuejs.org/guide/extras/web-components.html#building-custom-elements-with-vue
The idea as far as I understand it, is to create Custom Elements, that can be used anywhere, as a Web component.
Here (https://vuejs.org/guide/extras/web-components.html#building-custom-elements-with-vue) the developers specifically recommend using custom elements for component libraries.
Environment/Motivation
A client has a bigger UI Project that is based on other frameworks. He wants to switch to vue, but doesn't have the resources to completely rewrite/replace everything with a normal vue application. Therefore he wants to replace everything step by step by using webcomponents or more specifically, vue-components (with all the advantages of vue) that are compatible with his project.
Problem
The custom elements don't have global vue instance, because you don't mount a custom element, rather you mount a vue application.
However many libraries and packages like i18n, primevue, vuetify, (vuex), ... assume, that they are used in a global instance. At least their documentation requires adding them to the global app instance, otherwise, various features don't work.
Question
How can I use libraries that require a global vue instance to work, in the context of multiple custom elements?
Implicit Expectation
As a developer, I assumed, that major libraries like the ones I mentioned work for custom elements as well. I know that this requires each element to include a small "app instance", which I would guess could lead to performance issues.
For E.g. you create a Website with 100 custom elements with each having an app instance.
If these performance issues I worry about are not essential, then I still could create a classic Webcomponent where I mount a vue app on it. (Following this comment, which I tested and it worked with some adjustments: https://github.com/vuejs/vue-web-component-wrapper/issues/93#issuecomment-909136116)
I want to draw a diagram like below on the web and after drawing I want it to render the json string. I don't know what the idea is or is there any npm pulgin?
Take a look at this related and more general question about graph visualization frameworks for the web which has many different options for diagramming libraries.
Some of them work well with Vue.js but the majority has not been created specifically for VueJS. However integrating a library with Vuejs should not be a problem, as VueJS can easily be extended with third party UI components.
After all it's just JavaScript and the DOM.
Some of more elaborate solutions from the above answer show examples of how to embed a diagram editor and renderer Vuejs into your applications, but the integration is relatively straight forward, as you can see from this GitHub example showing how to integrate a graph visualization component with Vuejs.
Disclaimer: I work for the company that creates the library used in the last two links. However I do not represent my employer here on StackOverflow. You can use the same technique shown in the last link with most of the other libraries shown in the first one, too.
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
I'm already familiar with Knockout, Angular, Sammy, jQuery, a little breeze, and a little ember. The tutorials and getting started for Durandal all seem to be saying... well first add jQuery and maybe knockout.
Does it handle something entirely different than all of these?
What need does it address such that it is likely to be used with knockout?
Is it just a hodgepodge of client side routing and ui components?
What does it do on its own conceptually?
Durandal is similar to Angular in that it provides a MV* framework for client-side SPA web applications.
Angular is mostly, if not all, custom code, whereas Durandal takes existing libraries, mainly Knockout and RequireJS (Sammy dependency has been obviated with the 2.0 release), and provides the plumbing to provide full SPA functionality, including view/view model composition and hash-tag (spa) navigation.
As for Knockout, Durandal relies heavily on Knockout to compose the views and view models. Your view and view model are automatically data-bound when the view is injected into the DOM. The advantage to this is that I can use Knockout to provide the V/VM data-binding, and let Durandal do the work of figuring out which v/vm to use, retrieving it from the server, and composing it into the current screen.
Restated, Durandal provides a way to map views/view models to hash-tag based routes, which give you the SPA navigation. By specifying a shell, or layout, view as the main view, a placeholder can be added which Durandal uses to implement what is basically a "screen presenter" pattern. Durandal listens to the URL changes, and can automatically activate, data-bind (using Knockout), and display the view that matches the current URL route.
If you're familiar with WPF, you may think of Durandal as providing Prism-like functionality as its main offering, along with other goodies designed to support building single-page-applications for the web.
Durandal has several benefits, but also builds on existing libraries. It has a dependency on
RequireJS
Knockout
jQuery
These are not "maybes." They are hard dependencies. Durandal cannot work without them.
At it's core, Durandal add's the very powerful compose binding to knockout. This binding will automatically locate the view (an HTML file) when passed a viewmodel, retrieve it from the server, bind it to the viewmodel, and insert them into the DOM. Similar behavior can be achieved using the knockout template binding, but managing the templates can become cumbersome. Composition also adds lifecycle events to the process, which can help ensure that viewmodels are setup and torn-down correctly. It also provides optional DOM caching.
Durandal also provides some framework structure. It provides a simple plugin API, which is used by its router to give SPA navigation via hash or push-state. It encourages the organization of viewmodels and views by overridable convention, as well as the use of Require AMD modules. It also provides a simple event module to allow application wide events to be created and consumed.
Durandal is a "full featured" SPA framework, whereas Knockout is just data-binding. It is similar in scope to Angular.
Magento 2 stand on Knockout and RequireJS.
Durandal can be added on top of it so more possibility come with use latest features (components, templates etc).
It is better because:
it is more stable and major than other framework, less errors occur
great documentation
simple api
more SEO friendly! (you can have all html seved and use it like component, mixed situation). Angular 2 stand on mixing logic with presentation.
html5 standard data and binding with better code redability (just try read html in react)
still maintained
creator of Durandal was for some time Angular Developer (3 month) so there is some similarity going on there in thinking.
Work in old browser ! (IE6 >)
There also cons but mainly because it don't give so much function in one pack and not newly, cutting edge technology, was adopted.
Pleas share more point about Durandal :)
More there: https://johnpapa.net/compare-durandal-to-angular-not-knockout-to-angular/
I've heard about Windows Runtime Components, but seems like they are not applicable to UI components. Is it possible to create cross platform UI component (for example C#+xaml based component) which will run across all the projections C#, C++, javascript? I know projections are very different and need special environment to run, but if it's possible to create hybrid non-UI components maybe it's possible to create cross-platform UI components.
You can create components which expose UI to XAML apps, but you cannot create components which expose UI to JS applications - that's because the JS UI stack is dramatically different from the XAML rendering stack.