I'm learning the composition API, coming from a background with Vue 2 and the options API. I recall that within Mixins in the options API, we could not include components.
It seems that when writing custom composition functions, it is indeed possible to include components, and return them from the function.
Should I be doing this? I feel as though it may be bad practice given that Mixins did not allow for this
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 have posted a similar question on Salesforce stack where the context is Lightning Web Components(which is just an extension of HTML Web Components). I am asking here because I would like to reach a wider audience.
In their documentation they say that it is not recommended to get/set properties of a custom component in the connectedCallback() hook. Does anyone here know why would this recommendation be given, as I use this hook specifically for getting/setting properties.
There is no problem with reading or setting properties with connectedCallback callback handler. The original guidelines has to do with the fact that props can change after connectedCallback and this function is executed only when component is attached to the DOM tree. It means that your code will not be able to properly handle the reactivity.
It is not a technical constraint per se; it more like good architectural guidelines when dealing with web components.
General rule of thumb:
Use connectedCallback for one time stuff like templates, setting up observations (ensure that observations are cleaned up in disconnectedCallback.
Use getters and setters for managing the property watchers. Also, do not handle async workflows within setters. Example Promise.then(), etc. The reason for this is to properly handle the cancellation for already running requests when prop changes. Thus use observables preferably set in connectedCallback.
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.
I am starting a developement of a big project and I need to know if to use ViewEncapsulation None or Emulated.
From some reason the default is Emulated but I noticed that Angualr2 Material uses None.
We need to have reusable widgets within the projects and have different styles and also dynamic themes.
I know it's can be done with Emulated but is seems more difficult to manage and not as simple as using CSS rules or override.
What should be the recommended mode for such a project?
The benefits of using 'Emulated' option is, that You will be able to create encapsulated components(styles, template, etc.). Also it will help You to not only create component once(dropdown, table, popup) and reuse it within your current project, but also it can be used in different projects later or being open-sourced, if You will.
The recommended way is using the Emulated option.
It will give you the ability to encapsulate your component, not only the HTML template, but also the styles.
This is the future. It is called web components and I strongly advise you to read about it. For more details, see:
Modular future web components
Shadow DOM strategies in Angular 2
Now that AngularJS 1.0 is released I am wondering how this project fits together with the other general-purpose JavaScript framework / tool from Google, Closure.
I have only seen basic description of those two technologies (and read about a half of the book on Closure) so I have no direct experience but this is how it looks to me:
Closure is a set of technologies that can be used separately. What I find probably the most appealing is:
Closure Compiler which seems to "fix JavaScript" in a sense that it warns against typical issues, provides some compile-time checks (not all people like this but probably most Google developers do, and I do too). And of course it's nice that the resulting code is smaller and more efficient.
Then there are some parts of Closure Library that I like, e.g. abstractions over built-in types (ArrayLike etc.), class-based system, eventing mechanism, DOM abstractions etc. I'm not sure yet if I like the GUI library or not (seems to be quite complex and I didn't really have time to study it yet).
Then there are some features that I don't think I would find that useful, e.g. Templates.
AngularJS, which I've only read briefly about, seems to be much higher-level than Closure. It seems to be an application framework providing features like data binding, reusable components, MVC structure etc.
So these two technologies seem to be aimed at quite a different level of abstraction so my first thought was, can they be used together? Closure providing low-level compiler and browser abstractions while Angular providing application-level services and structure? Would it make sense and would it work well together?
The only Google project I'm aware of that uses AngularJS is the DoubleClick team. (presentation) Essentially, they still use Google Closure Library for everything but the UI building. Also note that they use Google Closure Compiler, but that's almost a given, "nobody" uses only the Library without the Compiler.
Google Closure Library comes with a UI framework in its goog.ui namespace. This framework compares in almost every way to non-web UI frameworks like Android, iOS, Swing and QT. They have a thing I like to call DOM elements on steroids, goog.ui.Component, which has lots of great life cycle mechanisms for garbage collection and event listening and more. You have things like goog.ui.Control, which is a subclass of goog.ui.Component, and handles user interaction in a very interesting way. It lets you plug renderers, for example, so you can change a <button> to an <a> without changing any of your other logic except the actual rendering.
Speaking of classes and subclasses, Google Closure Library also has this. You don't have to use the built-in one, the important part is that you somehow call the prototype of the "superclass" in your methods. You can for example use the class system in CoffeeScript, Google Closure Library doesn't care.
The reason the DoubleClick team chose AngularJS was apparently largely because of the data binding features AngularJS provides. There's nothing built-in in Google Closure Library to automatically update the UI when data changes.
So to summarize, Google Closure is a huuuuge beast, and AngularJS can replace the goog.ui part of the Google Closure Library.
I think AngularJS is more like a solid MVC/MVVM framework and Closure Library is a set of loose components, although both AngularJS Templates and Closure Templates have much in common.