search

status-im / status-mobile

a free (libre) open source, mobile OS for Ethereum
https://status.app
Mozilla Public License 2.0
3.91k stars 984 forks source link

The colors for netwroks attributes are not resolved during adding eth into watch-only address #19156

Closed VolodLytvynenko closed 7 months ago

VolodLytvynenko commented 8 months ago

Steps:

  1. Go to watch-only address flow
  2. Add a multichain ETH address to the "eth address" field. ( Example: eth:arb1:opt:0x42dd716de01943e40fc1d7f53feb4ffe16056c85)

Actual result:

The color is not resolved for eth:arb1:opt: attributes

Expected result:

The color is resolved for eth:arb1:opt: attributes

J-Son89 commented 8 months ago

@mmilad75 does your recent work on that address component resolve this. Perhaps it's separate but will use the same mechanism.

In any case, I think the network configuration for the watch only address stuff needs to be revisited so perhaps this issue could just be more generic and be to ensure the network configuration is working correctly & design wise for watch address flow?

shivekkhurana commented 7 months ago

I have a similar component with save address feature. The prefix is not added inline, but made available to select when you click the "Setting Knobs" button.

Here's the save address flow: https://www.figma.com/file/HKncH4wnDwZDAhc4AryK8Y/Wallet-for-Mobile?type=design&node-id=2087-615282&mode=design&t=c14riy23vGNdXsct-4

J-Son89 commented 7 months ago

@shivekkhurana , @VolodLytvynenko , please note that one example is an input the other is not.

Adding this to a text input component could be very complicated. @mmilad75 experimented with this and found this to be the case.

Perhaps we should discuss with designers about having plaint text within inputs unless anyone knows of a trivial solution for it

Parveshdhull commented 7 months ago

might be possible to implement using masked view - https://github.com/react-native-masked-view/masked-view

ulisesmac commented 7 months ago

@shivekkhurana , @VolodLytvynenko , please note that one example is an input the other is not.

Adding this to a text input component could be very complicated. @mmilad75 experimented with this and found this to be the case.

Perhaps we should discuss with designers about having plaint text within inputs unless anyone knows of a trivial solution for it

@mmilad75 What is the strategy that you are using?

I think if we generate the text hiccup instead of directly edditing the input might work :thinking:

J-Son89 commented 7 months ago

I will close this issue for now as we likely won't handle this 👍