Closed Lelelo1 closed 5 years ago
The Element Registry is a map of JSX constructor names to constructor functions.
So when you write <button>
in your JSX (as I do in the Button
class component), the Host Config will invoke the function in elementRegistry["button"]
to construct an instance of a NativeScript Button element.
register()
Registering a component allows you to add your own JSX constructor name
:instance constructor function
key:value pair into the registry. This allows you to make a JSX element such as <pullToRefresh>
be meaningful to the Host Config.
I figured that, as I was already importing all those NativeScript Core UI elements into that module anyway, I might as well re-export them all from the same module for user convenience. As you've found, it makes the imports more coherent and greatly helps auto-import (as Intellisense can find all of those imports after indexing just one file).
Yes, at least for version 0.11.0
of RNS, there's no harm in importing your elements from there – that's exactly what I designed it for. However, it sounds like the NativeScript Core team are finally implementing Scoped Packages for NativeScript version 6.2, giving us all the important imports from a single module (just like React Native!), so when that comes out I'll stop re-exporting those imports from ElementRegistry and you'll have to import them from NativeScript Core instead.
I went back to the first commits made to the repo and saw it was the first file created - separate from the index file.
It's purpose (?) seem to have been to supply HostConfig with the NativeScript components. Currently tough when wrapping plugins - there also seems to be a necessary
register()
call to the element registry.So it is not only a practical way of handling the ns imports?
Additionally I am tempted to grab all ns imports via the elements registry - as the imports then simply becomes more readable and coherent:
I assume there is no harm in doing that?