You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wondering if it makes sense for you guys to add borderStyle on view/text components. I'm looking for ideas for implement a dotted border around a sub-view.
I'd really love all those to be separate components like LinearGradient. This way we don't need to have a huge standard library that's super hard to maintain for edge case features like this.
@chirag04 - as @vjeux mentioned, could you try to make this into its own library for now? If it seems like something that would be a good fit for the standard library then it might eventually get pulled in. If you need a hand don't hesitate to ping me on irc as notbrent or shoot me an email brentvatne at gmail.com
@PhilippKrone - @chirag04 pinged me about this on IRC as he was working on it and needed a hand, I haven't had a chance to look at it yet though but will try to get you two something on the weekend! Added to calendar ;)
@brentvatne: Thanks a lot!!
One question, purely out of curiosity: would it have been possible to include this directly via style={{borderStyle: ....}}? What are advantages // disadvantages of both solutions?
@PhilippKrone It won't be possible to have it in style property but you would be able to use it as a component. like: . I will modify brent's work and then publish it to npm.
@chirag04 Mhh, no really satisfied by this answer to be honest ;) I'm already using it as component, but that somehow does not "feel right", to be honest. Let's assume I want my view to have a dashed border and - in addition - some other stuff for which I will as well built such components. Then I do have a lot of nested components instead of having it in the style property.
I'm already using it as component, but that somehow does not "feel right", to be honest
I agree that it isn't ideal!
Let's assume I want my view to have a dashed border and - in addition - some other stuff for which I will as well built such components. Then I do have a lot of nested components instead of having it in the style property.
You could combine these into a single component with a prop that switches between them and that would make it easier to manage.
You could even change it so that these are set through style! Look at how borders are implemented in RCTView.m and make the appropriate changes in a subclass of RCTView and it should work just fine, then when you want to have that kind of border you can use a CustomBorderView or even something more generic like PhilippsView 😄 that would incorporate all of your customizations. If you need help with this, ping me on irc @notbrent
If this becomes popular and there turns out to be a lot demand for integrating it into the core library then we would have an advantage of having an existing battle tested library that would be simple to integrate. But the problem is that any existing feature that is added to the core library needs to be-reimplemented on Android and maintained as it changes throughout releases, and as the surface area of the library grows it becomes harder and harder to manage. So the preference amongst the team right now (I gather from conversations on issues and in IRC, I don't actually work at Facebook or on the react-native team, I just help out when I can) is to build these in separate libraries and only integrate when demand is high and there is a compelling reason for why it would work better as part of the core library.
Hi @brentvatne: Thanks for your answer! I totally understand the opinion of the RN team here concerning not wanting to have everything in the core due to the reasons mentioned by you. I don't really know whether the thing I'm now proposing makes sense at all (as I'm not really deep into how RN works "behind the scene"), but what about the following solution in Objective-C (using javascript pseudocode here, as I'm not that familiar with Objective-C out of my head - please assume the following code is written in Objective-C 😃 ):
// register a new item for the style property// @param: name of style// @param: for which element// @param: handler functionmyStyleHandler.register('borderStyle',RCTView,this.handleBorderStyle);handleBorderStyle=function(prop){// copied from your code _border=[CAShapeLayerlayer];_border.strokeColor=[UIColorcolorWithRed:67/255.0fgreen:37/255.0fblue:83/255.0falpha:1].CGColor;_border.fillColor=nil;_border.lineDashPattern= @[@4, @2];[self.layeraddSublayer:_border];}
With such a way, it would still be "out of the core", and individual modules could be created (by different people) for different further CSS settings, but on the javascript side, you don't need to worry about that.
Does that make any sense?
Regards
Philipp
P.S. we can take this offline as well, if thats more appropriate. I'm "eimood" in #reactnative in IRC
I think borderStyle itself is something we can reasonably support in the core library, given that we already have a custom CSS border rendering implementation and border style is part of the spec.
For more general styling properties, the idea is that you'd have a bespoke component (e.g "FancyBorderView") and to use it via composition, rather than trying to inject additional functionality into RCTView.
The idea of rendering plugins for RCTView is interesting, but I'm struggling to think of a use case for such a plugin that couldn't be achieved with ordinary component composition.
@nicklockwood I can't think of a real use case as well at the moment, I just think that just because a certain CSS part is not implemented in the RN core should not mean to have it handled differently in the JS part, because basically, which parts are implemented in the core and which not was decided on specific use cases I think (at least thats what I was able to read from @brentvatne answer). So ideally, someone should just be able to write his styles in the standard View and just "load the styles", contrary to loading a lot of Views and somehow nest them etc.
Does that mean that borderStyle can/will get implemented in the core? :)
I'm not promising we'll add borderStyle to the core, but if we did there would be a fairly simple upgrade path - you'd just remove your custom wrapper view and apply styles directly (and if you didn't, your old code would still continue to function perfectly well).
The problem with allowing arbitrary extensions to RCTView is that if we were to later implement the same style in core, the semantics might be different, leading to crashes or unexpected behavior in your code.
Also, what if multiple different plugins tried to add extensions with clashing property names? What if you wanted to use two different components that relied on conflicting style extensions? Etc.
I appreciate that having to insert extra container views isn't ideal (especially if you come from the web world, where your node structure is supposed to reflect the semantics of your data, not its stylistic presentation), but it avoids all these problems.
Activity
vjeux commentedon Apr 14, 2015
I'd really love all those to be separate components like LinearGradient. This way we don't need to have a huge standard library that's super hard to maintain for edge case features like this.
brentvatne commentedon Apr 15, 2015
@chirag04 - as @vjeux mentioned, could you try to make this into its own library for now? If it seems like something that would be a good fit for the standard library then it might eventually get pulled in. If you need a hand don't hesitate to ping me on irc as
notbrentor shoot me an email brentvatne at gmail.comPhilippKrone commentedon Apr 30, 2015
@brentvatne Is there already an update concerning this feature? I'd love to use the css border-style as well :)
brentvatne commentedon Apr 30, 2015
@PhilippKrone - @chirag04 pinged me about this on IRC as he was working on it and needed a hand, I haven't had a chance to look at it yet though but will try to get you two something on the weekend! Added to calendar ;)
chirag04 commentedon Apr 30, 2015
@brentvatne Awesome. I look forward to you help. :)
brentvatne commentedon May 3, 2015
@chirag04 - check this out: https://github.com/brentvatne/react-native-dashed-border-example - feel free to take this and build your own library based on it
cc @PhilippKrone
chirag04 commentedon May 3, 2015
@brentvatne This is so awesome. Thank you so much for looking into this.
Looking at the codebase, seems like i had all these lines in my codebase. Just that i din't have them at the place. :(
👍 👍
PhilippKrone commentedon May 3, 2015
Hi,
@brentvatne: Thanks a lot!!
One question, purely out of curiosity: would it have been possible to include this directly via style={{borderStyle: ....}}? What are advantages // disadvantages of both solutions?
Regards and again thanks!
Philipp
chirag04 commentedon May 3, 2015
@PhilippKrone It won't be possible to have it in style property but you would be able to use it as a component. like: . I will modify brent's work and then publish it to npm.
PhilippKrone commentedon May 3, 2015
@chirag04 Mhh, no really satisfied by this answer to be honest ;) I'm already using it as component, but that somehow does not "feel right", to be honest. Let's assume I want my view to have a dashed border and - in addition - some other stuff for which I will as well built such components. Then I do have a lot of nested components instead of having it in the style property.
brentvatne commentedon May 3, 2015
@PhilippKrone
I agree that it isn't ideal!
You could combine these into a single component with a prop that switches between them and that would make it easier to manage.
You could even change it so that these are set through style! Look at how borders are implemented in RCTView.m and make the appropriate changes in a subclass of
RCTViewand it should work just fine, then when you want to have that kind of border you can use aCustomBorderViewor even something more generic likePhilippsView😄 that would incorporate all of your customizations. If you need help with this, ping me on irc @notbrentIf this becomes popular and there turns out to be a lot demand for integrating it into the core library then we would have an advantage of having an existing battle tested library that would be simple to integrate. But the problem is that any existing feature that is added to the core library needs to be-reimplemented on Android and maintained as it changes throughout releases, and as the surface area of the library grows it becomes harder and harder to manage. So the preference amongst the team right now (I gather from conversations on issues and in IRC, I don't actually work at Facebook or on the react-native team, I just help out when I can) is to build these in separate libraries and only integrate when demand is high and there is a compelling reason for why it would work better as part of the core library.
Hope that answers your question @PhilippKrone!
PhilippKrone commentedon May 4, 2015
Hi @brentvatne: Thanks for your answer! I totally understand the opinion of the RN team here concerning not wanting to have everything in the core due to the reasons mentioned by you. I don't really know whether the thing I'm now proposing makes sense at all (as I'm not really deep into how RN works "behind the scene"), but what about the following solution in Objective-C (using javascript pseudocode here, as I'm not that familiar with Objective-C out of my head - please assume the following code is written in Objective-C 😃 ):
With such a way, it would still be "out of the core", and individual modules could be created (by different people) for different further CSS settings, but on the javascript side, you don't need to worry about that.
Does that make any sense?
Regards
Philipp
P.S. we can take this offline as well, if thats more appropriate. I'm "eimood" in #reactnative in IRC
brentvatne commentedon May 4, 2015
Hey @PhilippKrone, that's an interesting idea, cc @vjeux
nicklockwood commentedon May 4, 2015
I think borderStyle itself is something we can reasonably support in the core library, given that we already have a custom CSS border rendering implementation and border style is part of the spec.
For more general styling properties, the idea is that you'd have a bespoke component (e.g "FancyBorderView") and to use it via composition, rather than trying to inject additional functionality into RCTView.
The idea of rendering plugins for RCTView is interesting, but I'm struggling to think of a use case for such a plugin that couldn't be achieved with ordinary component composition.
PhilippKrone commentedon May 4, 2015
@nicklockwood I can't think of a real use case as well at the moment, I just think that just because a certain CSS part is not implemented in the RN core should not mean to have it handled differently in the JS part, because basically, which parts are implemented in the core and which not was decided on specific use cases I think (at least thats what I was able to read from @brentvatne answer). So ideally, someone should just be able to write his styles in the standard View and just "load the styles", contrary to loading a lot of Views and somehow nest them etc.
Does that mean that borderStyle can/will get implemented in the core? :)
Regards
Philipp
nicklockwood commentedon May 4, 2015
I'm not promising we'll add borderStyle to the core, but if we did there would be a fairly simple upgrade path - you'd just remove your custom wrapper view and apply styles directly (and if you didn't, your old code would still continue to function perfectly well).
The problem with allowing arbitrary extensions to RCTView is that if we were to later implement the same style in core, the semantics might be different, leading to crashes or unexpected behavior in your code.
Also, what if multiple different plugins tried to add extensions with clashing property names? What if you wanted to use two different components that relied on conflicting style extensions? Etc.
I appreciate that having to insert extra container views isn't ideal (especially if you come from the web world, where your node structure is supposed to reflect the semantics of your data, not its stylistic presentation), but it avoids all these problems.
chirag04 commentedon May 19, 2015
I published DashedBorder component here: https://github.com/chirag04/react-native-dashed-border
Allows to set individual (left,top,right,bottom) dotted/dashed borders (
Merge 0.66 into master (#951)
Upgrade from 0.66.0 to 0.66.4 (#977)