I'm building a library of stencil.js components that will be published on npm.
Internally, my components use sub-components that I do not wish to expose to the outside world.
Is there a way to define a "private" components that can be used internally by other components in the same namespace, but are not exposed externally?
You can simply create a functional component which allows you to only render it inside of you parent web component, without exposing it externally.
Functional components:
aren't compiled into web components,
don't create a DOM node, don't
have a Shadow DOM or scoped styles,
don't have lifecycle hooks, are
stateless.
Please check this doc, it is quite straight forward to use it:
https://stenciljs.com/docs/functional-components
Related
I'm trying to write SSR-friendly code, keeping in mind a potential migration of my app from SPA to SSR. One of the principles of such code is to avoid statefull singletons which can cause cross request state pollution
The problem comes when I need to use an instance of Vuex, Vue-router, Vue-i18n etc. outside of Vue component. Because the solution in all the respective SO answers is... You guessed it. To create and export a statefull singleton in a separate js file and then import it all over the app:
Vue-router: https://stackoverflow.com/a/43562210/11208064
Vuex: https://stackoverflow.com/a/47575742/11208064
Vue-i18n: https://stackoverflow.com/a/66695008/11208064
A simple example
// store.js
export default new Vuex.Store() {} // this is a singleton
// someOtherModule.js
import { store } from './store.js'
Pinia has covered the issue in the docs. They recommend to access the pinia instance via app.$pinia. However they don't specify how do I access the app instance itself.
Also the problem is not limited to these libraries. We write our own modules which work in a similar manner.
Researching the issue I came across this article. It suggests to wipe module cache, so each time you require it all the code is executed again, making it fresh and stateless. Sounds pretty sophisticated, but maybe this is the way? And if not, what is the recommended solution?
Recently I found out that composition API lifecycle hooks can be used within options API components.
For instance, I'm using beforeUnmount hook inside mounted of composition API, and the hook is called correctly.
https://codesandbox.io/s/testing-onunmounted-vue-3-2-4e8x61?file=/src/components/test1.vue
There is not much information regarding this topic yet. On the documentation page, there is a hint saying:
For shared usage of lifecycle hooks, see Guide - Lifecycle Hooks
But it leads to an incomplete page with little information regarding this subject.
So I wonder if it is acceptable using composition API lifecycle hooks this way? Am I missing something?
I am getting start to study Context API of the React Native.
I understand that the Context API is to solve the problem to send a lot of props in the parameters.
It seems to me as a global variable.
In this case, to use a static variable of a class in JS don't fix the problem of a variable global?
Why use Context API when we can use a static variable?
What are better in Context API?
Are others API that use Context API in React Native as pre-requisite?
In my experience you can do exactly as you're describing...
You'd set a static property App.instance = this in App's constructor.
Your App class has static methods which can access App.instance.state and App.instance.setState().
I'm curious why this approach isn't mentioned anywhere. Possibly because you can't use static properties in functional components, so it's a bit unfashionable. And it feels like it goes against react's component tree structure.
There is also the general feeling that statics are evil.
Maybe I'm y bit too careful here. I create a component with createApp programmatically and mount it on a DOM node. Later, I remove the DOM node from the DOM tree.
Do I have to make sure to call unmount before removing the DOM node (with the mounted Vue3 app) in order to avoid a memory leak? Or is all data maintained in properties of the DOM node created during the mount? The documentation doesn't mention this explicitly (or I failed to find anything).
Explicit unmounting seems natural according to general resource allocation/deallocation rules. No need for explicit unmounting also seems natural as this is a garbage collecting environment.
Summary: Can Vuex modules be made $store references in .vue components (instead of referring to the Global Store as it is now after Vue.use(Vuex)) ?
Details:
I read this: vuex modules and I get that the global store can be composed as a bunch of vuex modules.
This is great but is there also a way to make these vuex modules the $store references within vue components instead of $store pointing to the global store (as it is now ?).
This will be mighty useful (IMO) since vue components then have to only be aware of its local store's references (or their own vuex modules); and, how they compose the global store.
Please advise.