|
View your CI Pipeline Execution ↗ for commit 5cccbdc
☁️ Nx Cloud last updated this comment at 2026-04-03 19:54:53 UTC |
Sorry, something went wrong.
|
Omg! BIG! |
Sorry, something went wrong.
| // NativeScript | ||
| // | ||
| // Created by Osei Fortune on 17/02/2026. | ||
| // |
There was a problem hiding this comment.
We could put this in widgets to be included in the .xcframework, that way it's prebuilt and doesn't imply an extra build source on end users.
Sorry, something went wrong.
There was a problem hiding this comment.
I'll reject the PR to keep this reminder and we can work together to do this part.
Sorry, something went wrong.
| // NativeScript | ||
| // | ||
| // Created by Osei Fortune on 17/02/2026. | ||
| // |
There was a problem hiding this comment.
I'll reject the PR to keep this reminder and we can work together to do this part.
Sorry, something went wrong.
| } | ||
| [filterProperty.setNative](value: string) { | ||
| // LayoutBase, ImageView and StyleableTextView has the setFilter method implemented in the native view, so we need to check before call it. | ||
| const nativeView: globalAndroid.view.View & { |
There was a problem hiding this comment.
@triniwiz Instead of creating a union type here, I have the following thought.
Let's create an interface in ui-mobile-base/widgets (e.g. ICSSFilter.java) with the needed methods and let ImageView, LayoutBase, and StyleableTextView implement it.
This way, we'll have an interface as a type for Java-side and a type in types file to use in TS-side.
Sorry, something went wrong.
| return cm | ||
| } | ||
|
|
||
| internal fun parseCssColor(value: String): Int { |
There was a problem hiding this comment.
@triniwiz @farfromrefug I'll just leave my thought on this one for both android and iOS.
This PR adds maps of colors for each platform and adds color parsing methods on native side.
I understand it all stems from the fact that it's cheaper to pass the raw string from core to native but is having duplicate functionality worth over let's say being afraid of passing more complex parameters to JNI calls?
I was thinking core could at least parse the color values alone since we already have the color module that already does that much.
So, filter property could have a valueConverter for converting the color values only and pass everything as parameters to native methods afterwards where everything else can be parsed.
Sorry, something went wrong.
There was a problem hiding this comment.
Atm this follows the web of taking a string input then building the filter from said input. Nothing wrong with keeping this in swift/objc or kotlin/java
Sorry, something went wrong.
Add support for css filters e.g drop-shadow(16px 16px 20px red) invert(75%);