← Back to the summary 19 Weex Rendering Bugs That Will Haunt Your Cross-Platform Build
text/div font style settings may differ; for example, font-weight on a div may not take effect.background shorthand doesn't work; you must use background-color and background-image separately.- On Android, every
div needs explicit width and height. Elements expanded by content fail to render correctly when positioned.
text placed directly at the same level as flex:1 sometimes loses its style; wrap the text in a div tag.- Browsing H5 in the Baidu app causes session changes that refresh and log the user out to the login page.
- Weex upward loop scrolling occasionally leaves the first element stuck.
- On Android, after a timer stops, restarting it fails to execute; calling an empty timer again restarts it.
- The
refresh component cannot be dynamically shown/hidden; you can change the pull-to-refresh component position via layout.
- On iOS, after setting
background-image via style, setting it to empty doesn't work; set the color to transparent instead.
- On iOS, the pull-to-refresh component's background only covers the height area; handle it with an underlying layer. Android can set background color on
refresh normally.
- On Android, if CSS sets a style and then
style is set again, flickering occurs; remove the CSS style (appears with offer number scrolling and the king kong area slider).
- On iOS,
box-shadow causes overflow to fail.
- On HarmonyOS and H5, using
translate to drag an image component off-screen with transition-delay causes the image resource not to load — it loads only after user interaction.
- On iOS, if a rendered component gets data with too large a difference on pull-back, it disappears because of
key.
- On Android, using
transition to switch styles causes all styles except a few supported ones to fail. Wrap the transition element and other styling nodes separately — e.g., for button size and position transitions, wrap the border-radius and color changes.
- On iOS, if the four values of
border-radius are written separately and are inconsistent, it doesn't work; use image slicing or element stacking, depending on the scenario.
- Weex's web side doesn't implement the
richtext component and tags; use with caution.
- The syntax for writing the four borders separately doesn't work on Android and iOS; if you want to draw a three-pointed arrow, slice images.
- Weex single-line ellipsis with
white-space: nowrap; doesn't show the ellipsis on HarmonyOS.
Top 2 of 4 from juejin.cn, machine-translated. The original thread is authoritative.
The first item isn't "maybe" ineffective — it's definitely ineffective: font-weight in Weex belongs to text styles, only applying to text / input / richtext; div has no font concept. And the documentation says iOS supports 9 levels from 100 to 900, while Android recognizes only 400 and 700 — any other number is forced down to 400 or 700. So a design-specified 500 Medium will definitely be thinner on Android; tweaking the number won't help, the only approach is loading the Medium weight via font-family.
Whoa, there's a pro here. Your company is still using this? [watching]
Still using Weex?
The previous company was using it, probably won't anymore, wasted two years of my time, sigh [crying]