I would like to create a web component which is an auto-complete combobox, but since there is no such thing natively, is it considered bad practise to make a web component which also depends on a third party library or libraries?
I've only had some minor involvement with Polymer a year ago, and now that v1 of the spec is out, I'm looking at them again. It seems to me that most people develop web components that are 100% plain javascript with no external dependencies, but given the state of UI controls available, that would make for some very plain-Jane components.
There are two ways to handle this. OK. Maybe more, but I will show two.
1) Rely on ES6 imports and then your components just use `import something from './somefile.js". Yes, you will have to provide both the component and the library or reference a library that supports ES6 imports. But this prevents doubling up code.
2) Package your components with their dependencies. Some people use things like Webpack, but I felt that was going too far so I created component-build-tools to allow you to write your components using import but then combining the components parts into a single file. This allows the components to be loaded in any browser even if they don't support import. The limitation here is that you need to load your combined component files in the correct order. For most projects this isn't difficult, but it is something you need to manage.
Related
I heard a lot of good things about using the MDX (mdxjs) format in Next.js applications, they say that it is very convenient to make simple blogs this way, for example. As far as I know, custom elements can be used in MDX, but I've heard somewhere that using custom elements from other UI frameworks is difficult because you need to install a bunch of additional NPM plugins, packages, etc.
I have never used these technologies and could not find any additional information about my question, so I wanted to ask if I can use MUI5 components directly in MDX in Next.js by wrapping them as custom ones?
I'm starting a new website from scratch and I was wondering if React UI Framework are worth the try for building a website, or it's better to create my own components, grid etc...
I really like projects such as ElementalUI's Take on bootstrap3, MaterialUI forms components, Grommet, but they don't mix well together, some are using SASS, other LESS...
During previous projects, I've used some UI frameworks, but when I needed to do something that was not thinked by the creator of the framework, it was less complicated to create it myself than finding a workaround, and often more elegant.
I'm thinking that building my own React components using SASS and CSS3 could be the best solution.
Thanks!
This is an excellent and complicated to answer question at the same time.
I've been involved in few React projects, with different teams, and most of time, we were composing our components sets with customs style and when we needed a specific thing, the way to go was npm, for instance a custom range date picker.
Full disclosure; I wrote a great deal of ElementalUI.
I recommend researching each of the available UI frameworks and deciding whether they have the components and functionality required for your project. I also recommend looking into the components themselves to see how and why the authors solved a problem the way they did - that's probably the most valuable thing.
Elemental, and most other frameworks, are really helpful for applications where the UI must be consistent throughout. My own experience has been that for websites you're better off building your own components.
Since my application is getting bigger, I decided to fragment my project into several modules, but the documentation from Swiz on Modules is very poor (http://swizframework.jira.com/wiki/display/SWIZ/Module+Support). I tried out the Swiz Examples (http://www.briankotek.com/blog/index.cfm/2010/8/16/Swiz-Example-Application-Demonstrating-Module-Support) but I couldn't inject any data into my module or even catch an event. The module is loaded properly however.
Ideally I will end up having multiple Flex-Projects, each containing one module and each .swf file is deployed into the application deploy folder.
However if you aren't famililiar with a structure like that, but instead you know how to inject data/event mediating into a module inside the same Flex project, I'd also be happy to read your advice/knowledge.
Any helpful answers welcome.
I don't know Swiz, but I have had great results using SwiftSuspenders - you can have very complex modular structures completely decoupled and loaded separately.
What might be an issue you want to check first, though, is which ApplicationDomain you load your module into: If you are going to use a common class loader, inject data and catch events properly, it should be loaded into currentDomain.
In any case - SwiftSuspenders is worth looking at...
I have a project where we are trying to skin Spark components from a third party library that are built up from the drawing API primitives. Our first attempt involved creating a Flex skin (SWC) in Illustrator/Flash and applying that skin to the Spark components via CSS. We found that even with only a single instance of one of the components skinned in this way on stage, the application was brought to it's knees. For example, it failed to respond in repaint scenarios in a timely manner, and exhibited all the symptoms of being hung.
Our next approach will be to recreate the same skin artifacts in MXML classes that are in turn associated with the third-party components. Although the complexity of some of the skins leads me to believe that we might not avoid performance problems with this approach either.
My question is the following: Is there a correct or recommended way to apply either a SWC or based skin to a component that is built up from the Spark drawing API to begin with? Even as I ask the question I recognize that the approach means using the Spark drawing API in two places and will probably have unexpected consequences.
I've had good luck building the skins using MXML skin classes that inherit from s:Skin in terms of rendering performance. The recommended method (from Adobe) is to start by copying an existing skin file from the SDK and modifying the MXML to suit your needs. Regarding drawing, FXG works very well for defining how you want the skin to be drawn. FXG is XML based, so you don't need to write ActionScript to do your drawing, like we used to do for Flex 3 programmatic skins. You can also create skins using Adobe Catalyst. I have not used Catalyst, so I can't speak to its effectiveness, but many people seem to like it. Hope that helps.
Can anyone tell me what is and isn't recommended when it comes to mixing in classes from the mx package in an Actionscript only project?
Specifically I want to use AsyncToken, IResponder and HTTPService classes in the mx package in an Actionscript project.
I guess the mixing problem comes when you need to use mx.* classes, but you're on a pure as3 project.
If it's as3, you can still make an actionscript flex project, using the framework.
When it comes to Flash, you can either export a SWC with your actionscript exported (linkage setup) and add that to your flex project.
Again, if your project weighs more on the flex framework than on flash, you might find the Component Kit handy.
But if it's a Flash IDE more oriented project ( as in simple data coming in, mostly design work, not much nerdy stuff to it ), using a few mx.* classes, just for the HTTP service, doesn't make much sense. The problem comes with the fact that flex is a framework, therefore things rely on each other to work well, like a brick tower...brick upon brick, upon brick...
and since it's code you're working with, things are somewhat dynamic, but still not much cement...so you might end up wasting more time finding all the flex dependencies and getting them to work outside the medium they were made for, rather then building some of the functionality by hand.
If you need an as3 only implementation for WebService, Carlo Alducente has one.
HTH
The non-visual mx classes should work fine in a AS3 only project. But they have a lot of dependencies so you SWF will be bloated.