-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Home landing page #4178
Home landing page #4178
Conversation
js/src/util/ethlink.js
Outdated
import base32 from 'base32.js'; | ||
|
||
// base32 alphabet should match the Rust implementation | ||
// https://github.com/andreasots/base32/blob/master/src/base32.rs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be great to have a non-volatile link to a specific commit in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not even close to having that - we are still actually in development here and finding what works between the platforms without decoding issues.
(At this point is a align-tests between platforms, push, build binaries and test exercise - that comment is due to "tracking between days" to not lose context.)
Updated. |
The dapps and the accounts looks very similar and I think it would be easier if it were one component. The link and the title should be the only thing that differ, as well as the image. No ? That's when the cursor is over the dapps zone, but not over a dapp That's when the cursor is outside the dapps zone |
> | ||
<Link | ||
className={ styles.link } | ||
to={ `/${history.type === 'wallet' ? 'wallet' : 'accounts'}/${history.entry}` } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to connect this component to the Redux state, so it can directly check if it's an Account, a Wallet or an address. The link URL would be generated accordingly.
The point being that if I visit an Account and then delete it, it would still show up in the history and the link would be broken. The parent component could be connected not to render this deleted Account though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 Good point.
js/src/views/Home/News/news.js
Outdated
body: item.style ? (item.style.body || {}) : {}, | ||
head: item.style ? (item.style.head || {}) : {}, | ||
tags: item.style ? (item.style.tags || {}) : {} | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not simply { ...item.style }
? Could filter which key with lodash/omitBy
if necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is due to evolution over time and figuring out what makes sense. { ...item.style }
would be preferable.
js/src/views/Home/News/news.js
Outdated
); | ||
} | ||
|
||
retrieveNews () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we have a simple MobX store for that ? Would be great to have it as a singleton to be able to cache the result (and update if necessary). When you switch back to the home page without leaving the UI, there is always at least 1 sec without the news displayed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, been to-and-fro-ing this one in my head. Feels like overkill (store for 1 call), however the singleton actually does make sense here, just because of the delay. Will update.
return ( | ||
<SectionList | ||
className={ styles.news } | ||
items={ newsItems } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it limited to 3 news ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More sections goes into the next line, so there can be as many as we want.
if (extensionStore.hasExtension) { | ||
window.open(this.props.store.currentUrl, '_blank'); | ||
} else { | ||
router.push('/web'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be a proper a
link instead ? As it's just a link, using the standard attributes sounds a bit more logical (just thinking about users with no extension that want to ctrl+click
on the link to open the dapp in a new tab)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It becomes quite hairy and very messy prior to <base36>.web.web3.site
support for the internal dapps -
- Internal vs external to use Link (internal) and a (external)
- Still need to set set the currentUrl in the Webstore before opening
/web
Could probably re-look at the implementation with an issue, here though I am not going to touch everything down from Web/Store and re-imagine the world. So I would suggest logging as an enhancement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes ok, I haven't seen that the Browser dapp don't take into account the real browser url.
Updated.
As for similar components, in isolation, yes. However these would need to be replaced by standard summary components as soon as we get to the Accounts/Address/Contract/Dapp overlay-change PRs. (So really don't want to add generic component work here to turf it 3 PRs down the line especially without seeing what the needs are across views.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, looks good now. The only thing is when you click on a dapp, and then on Parity to go back to the UI, it navigates to the dapp view, instead of the previous home view
Actions -
views/Home
that shows the actual components (urls, dapps, news & accounts - all historic)/home
route & menubar item (replacing previous non-clickable image). This is now the default landing page.In action -
https://youtu.be/eGngA2lj3Gk
Additional required dependencies -
utils/dapplink
to encode<token+url>.web.web3.site
URLs, Web view with web3.site support #4313DappUrlInput
component fromviews/Web
, allowing the re-usable entry of a web URL, Web view with web3.site support #4313views/Web
into re-usable store, Web view with web3.site support #4313