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.
Related
Not sure it's the right question for this forum, but I couldn't find another place for it.
Our design team built their design system based on fluent ui libraries as described here. They downloaded the design from here.
Unfortunately, our engineering team is using Angular, so we naturally reached for the option of web component but found out to our surprise that the library is completely different - different set of components, abilities, and of course - a completely different design.
I thought that all fluentui platforms are supposed to be an implementation / interface of the same design. Why is this not the case? What am I missing?
Is there a way we can use the design described in here in Angular? (Except actually using the react library inside my Angular project).
Thanks for helping and very sorry if this question is inappropriate for this forum.
fluent web components integrated with angular.
take a look at documents
I develop my own vue components library, and this components have a lot of texts that needs to be localized. vue-i18n doesn't support this, because it should be attached to Vue (e.g. Vue.use(VueI18n)), but in case of component library, it will result in conflict.
I need to have independent translation files in my library, totally separated from my application (to prevent conflicts)
I'm struggling to find any answer to this question in other sources, and I hope someone can give me example for this case. Thanks in advance.
Well it really seems that vue-i18n is not tailored for use in component libraries for reasons you are mentioning (attaching itself into Vue.prototype + conflict with user's code).
I don't know what features of vue-i18n are you using but if it's just simple translation, it seems rolling your own custom solution with an option to plug in the i18n library of user's choice would be the best. It's not that hard. Most of the component libraries are going that way...
You can take a look at how "big guys" do it - in this case Vuetify.
Docs
Code
I have been trying Vue.js with ASP.Net Core for the last week and it seems quite powerful.
However, I have seen different approaches in the way how files are organized and modules written.
In the javascript spatemplate, they use, I would say this structure with ts, html, css files:
|_components
|_counter
*counter.ts
*counter.css
*counter.html
In other starter Vue.js templates, we have this structure with one single vue file:
|_components
|_counter.vue
Is there a limitation/advantage in using one over the other? Is one being more recent and should superseed the other format?
I have also see that they are different way of writing component for Vue in Typescript.
The default one presented on the Vue website and the other way using the vue-class-component or the vue-property-decorator which looks more natural to me and is recommended on the Vue website as it seems to solve some issues: link.
Again if it is that good, why shouldn't it become the standard? Does the default style gives more flexibility compared with the 'vue-class-component' style?
Sorry for the basic questions, just trying to get the good directions from the beginning.
I'm a beginner in dojo. First of all is everything javascript based? For example to create a form I have to use JavaScript or HTML tags?
Also I cannot understand their documentation and tutorials. It's very confusing.
Is there a proper website (other then dojo itself) that has good tutorials?
You can use Dojo's components's (widgets) in two ways. Programmatic and declaritive. The programmatic way (what you are talking about) is by defining widgets through the use of javascript. With declaritive you can define them using HTML markup. David Walsh has a nice short writeup and if you search for "declaritive programmatic dojo" you'll find some questions and answers on the matter:
https://davidwalsh.name/dojo-widget
Difference between programmatically vs declaratively created widgets in dojo?
Declarative coding or programmatic coding in Dojo Projects?
Declarative or programatic approach in DOJO?
If you're having trouble with the tutorials on the Dojo website, i suspect you're better off, first diving into some basic beginner javascript tutorials before trying to learn a framework like Dojo. I concur with the comment Ferry made on your question, there are no better resources than the actual Dojo website. I recommend following every tutorial, starting with the Hello Dojo tutorial and working your way up so that you don't miss out on the basic concepts which you'll need when you read the harder tutorials. Good luck!
For your first question: dojo is javascript-based platform that provide you with a basic javascript library and a bunch of basic widgets (UI controls like button, dialogue, layouts,...), and some extra things. However, you don't really have to use dojo all the time: you still can use dojo to manipulate a html form button; it's just dojo button comes with extra functionalities and might save you some time.
For the second question, I agree with iH8 that dojo website is the best place to start. There are three different ways dojo websites can help you:
Look at the tutorial: Basic steps on how to set it up and use provided functionalities as-is
Look at thetoolkit api: This provides a very detailed view of dojo javascript object (See what extra things you can do with dojo objects)
Look at the nightlytest: I found this very helpful in term of showing me what can be done outside of the tutorial (i.e. how to use things you found in the api)
Other than these, you can look at existing implementation to learn about the toolkit.
Basically, this is how I am learning Dojo. Without more-specific questions, it's hard to tell what is confusing about the tutorial. I would recommend you give it a try and post a question: everyone here will be willing to help you.
I recommend starting with some video tutorial like this.
When you understand the concept, you can try to copy and paste some code from Dojo documentation tutorials or Reference Guide, because all books are out-of-date.
Also you may find some useful information on IBM-related sites like http://www.ibm.com/developerworks because IBM invested in Dojo and uses it for its products.
If you have enough resources ($) you can take participation in Workshops (sitepen.com/workshops)
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!