Is your feature request related to a problem? Please describe.
At present, FlexboxLayout is portrayed as the UI component that should be most familiar to web developers. However, it is lacking various features that <div> offers for Web, and is less functional than the popular and powerful <View> component abstraction from React Native (which is comparatively easy to adapt to). It's hard to sell mobile developers on using React NativeScript if even the most basic UI building blocks are not on par with those of React Native. It's also hard to sell web developers on using any flavour of NativeScript if it's hard to produce layouts equivalent to those on the web platform.
Of significance, the development of a view component like this, that is more in line with the capabilities of a <div>, would greatly ease the implementation of a NativeScript Web library (whether by the core team or by the community).
As far as I can find, FlexboxLayout implements the following layout/display properties:
ViewBaseleft and top)minWidth, minHeight)Missing:
right, bottommaxWidth (#1511 ), maxHeightViewwidth & height)marginvisibilityopacityMissing:
outline (but React Native doesn't have this, either)LayoutBasepaddingFlexLayoutflexDirection, flexGrow, flexShrink, flexWrapMissing:
display (note: React Native restricts this to "flex" or "none")positionLabel, <TextView>, and <TextField>.AbsoluteLayout in order to achieve equivalent layouts to those of Web or React Native.Describe the solution you'd like
Either directly augment, or implement an extension of FlexboxLayout (called DOMView, for example) that has feature parity with React Native's <View>. The main things missing are position and display support, but maxWidth, maxHeight, right, and bottom would also be needed for a thorough implementation.
I would strongly suggest approaching this by migrating to Facebook's Yoga flexbox-based layout engine, which supports all the aforementioned missing style properties, and acts consistently between Android and iOS due to being a cross-platform C++ library.
Describe alternatives you've considered
We can possibly achieve the same by nesting AbsoluteLayout within a FlexboxLayout, but this raises performance concerns (more layout bases than necessary).
Additional context
By achieving parity with React Native's <View>, which is a well-loved equivalent to a "display": "flex" <div>, it will be easier to attract people to use React NativeScript so that they don't feel that they're making a step down from React Native. It would also be vital for allowing React NativeScript to interoperate with React Native (and thus also React Native Web) codebases one day. This is particularly important for consuming the enormous ecosystem of React Native UI modules.
Related:
A couple things:
Are you aware you can wrap the Yoga in your own plugin, then use it in your apps. They normally try to keep Core simple; there have been many "trivial" plugins that add requested functionality because they just want to keep Core simple. Adding Yoga would add a lot more code...
'Display' isn't needed; if you need to hide it you can use visibility='collapsed' or visibility='hidden'
I don't disagree on adding right, Bottom, maxHeight, maxWidth -- their have been many times I wished these existed...
what does 'outline' do, I'm not actually familiar with that one...
@NathanaelA
Are you aware you can wrap the Yoga in your own plugin, then use it in your apps.
I did try importing yoga into NativeScript (using its JS bindings for node.js) to try to implement this myself, but I couldn't get it to run because node.js was evidently too different. Someone with more expertise in ironing out those differences or the smarts to handle the C++ library directly might have more luck.
Adding Yoga would add a lot more code...
That may be the case (I'm not actually sure how big it is compared to the Android/iOS implementations we're using currently). However, it does pay its rent with a great number of new features and cross-platform consistency. It might even run more quickly than the present implementations due to being C++-based (pure speculation, however).
'Display' isn't needed; if you need to hide it you can use
visibility='collapsed'orvisibility='hidden'
I forgot about visibility='collapsed', thanks. Feels like display could be aliased to that to reduce bewilderment, but then there's the difficulty of how they'd interact.
I don't disagree on adding right, Bottom, maxHeight, maxWidth -- their have been many times I wished these existed...
👍
what does 'outline' do, I'm not actually familiar with that one...
It's a style for debug purposes more than anything. It paints a line around the area of the element without influencing layout whatsoever.
They normally try to keep Core simple; there have been many "trivial" plugins that add requested functionality because they just want to keep Core simple.
A tentative thought: What if it were developed as a separate optional module (just like the RAD UI components) to install to augment the more lightweight core UI modules?
Mainly I don't know how lightweight/heavyweight it is. I think React Native Hello World apps tend to have a smaller footprint than {N} Hello World apps, so it can't be that big if anything.
Out of my own curiosity, I looked at the Yoga libraries; it does seem like something that a we could create and have working fairly well fairly quickly. After I finish with all my projects in my queue; I might take a crack at it...
@shirakaba - is outline just this https://bradmartin.net/2018/03/05/native-layout-inspection-with-android-emulators/ on android where you turn on debug layouts in developer settings. It paints the border lines of the view but also you can see the margin between the layout/views as well. I'm unaware of an iOS equivalent but curious if that's the outline you're referring to.
@NathanaelA Wow, thank you very much for the interest! Please do report back with any findings if you get a moment to have a play with it. If an implementation for a NativeScript DOMView comes into being, I can set up a project to run all the React Native <View> test cases on them.
@bradmartin I'm referring to CSS outline rather than any specifically native concept. Android may well have a direct equivalent, but indeed I'm not aware of iOS having one (as React Native never implemented one).
@NathanaelA is right - NativeScript team is less likely to include a whole new layouting engine in core modules. However, I had something else in mind - creating an universal Layout component, which to support all other layouts and to be easily controlled with properties and CSS. The other layouts can inherit from it for compatibility purposes. This will probably come close to the functionality of Yoga's View, without actually including the library in {N}. Text can be handled with TextView component, which is similar to React's Text component and supports FormattedString for further text formatting (I'm trying to improve the vertical align support in there to better match Web).
The CSS outline main usage is for accessibility purposes/keyboard navigation on Desktop, not sure it has any usage in mobile, beyond physical keyboard support, which is limited in both platforms at best. For debugging setting borders can be a good substitute, but better DevTools support will be much more welcome. :)
@bundyo Thank you for your input. I've accordingly renamed the issue to reflect that yoga is not necessarily a part of the equation. A universal layout component is an interesting concept. My only concern is that the "dock" and "grid" layouts don't exist in HTML (CSS Grid is something different, to my understanding), so the component wouldn't map 1:1 with it, and would therefore introduce complications if making a NativeScript Web library. If anyone used "dock"/"grid" modes on this universal view, it would have to be special-cased or simply ignored when transpiling to Web. Otherwise, however, it does address most of the points of my issue and I'd be satisfied with it as a solution.
Text can be handled with TextView component, which is similar to React's Text component and supports FormattedString for further text formatting (I'm trying to improve the vertical align support in there to better match Web).
Matching <Text> is a whole different story, as NativeScript is quite behind here compared to React Native. I was planning to file another issue for that, as there are a lot of things to specify for it. I tried running all the React Native Tester tests against my best NativeScript equivalents to the <Text> components, and there were all sorts of issues and feature gaps. But above all, there was slowdown. With equivalents to both <View> and <Text>, though, we'd have a really good on-boarding story to sway React Native developers to React NativeScript. The components would naturally be useful in other flavours of NativeScript, too.
As for CSS outline, border is an okay substitute, but it potentially affects layout (depending on the border-box mode we use by default, which I don't know) – and things get complicated when a border is already in use. Yes, it would be great for DevTools (to show which element is being highlighted), and iOS/Android do have accessibility features similar to outline, but I'd expect that they're already handled automatically by the native views without NativeScript having to toggle anything manually.
I have not completely thought it through but can't the NativeScript Placeholder be used? ts/js can be generated from the native code (like how it is done with libraries): from View - and then provided to the placeholder component. I think some functionality still needs to be put in in the nativescript component - but I am not sure which.
@Lelelo1 We're far from being able to trivially generate a usable UI component from the native code of React Native; that's a big project that requires a lot of expertise from both RN and {N} developers. A key obstacle is that RN components fundamentally lay themselves out and manage themselves via a different API to what NativeScript uses. Not to mention, this is complicated by the fact that RN has to dispatch all its UI operations back and forth over a bridge.
I think that, one day, consuming UI modules directly from RN will be possible, and it will be sensational once it becomes a reality, but for now I don't even know where to begin with it. A halfway point would be to achieve much of its functionality by bundling half of React Native along with NativeScript and mapping relevant API calls between the two (praying that there is a perfect 1:1 mapping and that it's trivial to strip out the bridge), but of course the added bulk is undesirable by anyone's measure. I'm open for any further ideas on this front, but I think that practically it would involve a lot more work than either Bundyo's idea or my own Yoga-based suggestion (which I suspect are actually reasonably surmountable projects for people with the right knowledge).
Most helpful comment
@NathanaelA is right - NativeScript team is less likely to include a whole new layouting engine in core modules. However, I had something else in mind - creating an universal Layout component, which to support all other layouts and to be easily controlled with properties and CSS. The other layouts can inherit from it for compatibility purposes. This will probably come close to the functionality of Yoga's View, without actually including the library in {N}. Text can be handled with TextView component, which is similar to React's Text component and supports FormattedString for further text formatting (I'm trying to improve the vertical align support in there to better match Web).
The CSS outline main usage is for accessibility purposes/keyboard navigation on Desktop, not sure it has any usage in mobile, beyond physical keyboard support, which is limited in both platforms at best. For debugging setting borders can be a good substitute, but better DevTools support will be much more welcome. :)