3c42360b30
Add acquisition backend methods Init referrals sharing UI Add invite on home screen Use i18n for strings Lint Update status go Pull acquisition contract to get SNT amount Use new invite component f pulling go Use screen instead of bottom sheet Handle android install referrer Post referrer to backend if present go go Add async storage for referral decisions Update with the stage backend Update contract methods Modal UI Full handling of advertiser type UI test UI Handle with universal link Allow multiple acquisition per installation Fix android bottom sheet Do not call service if no click-id received Disable invite in release Parse query params for referrer Adapt UI changes Add push notification update deps Mock react-native-push-notification Request push notifications permission on press accept Store transaction to local storage and load it back on login Separate acquisition into smaller ns Add chat invite Get referrer only on first install fix string Fix firebase crash Handle outdate click-id Cleanup business logic Update contract Revert pn Minor update to advertiser modal copy OLD - Welcome to Status! Here is some crypto to get you started NEW - Here’s some crypto to get you started! Use it to get stickers, an ENS name and try dapps OLD - By accepting you agree to the starter pack NEW - By accepting you agree to the referral program upgrade status-go Add mainnet Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
Status Quo Components
All components in Quo should be independent of the app state. They should be pure,
and easy to reason about. This is required to make the library independent and
easily pulled off as a separate repository when needed.
Do avoid high coupling and direct use of internal styling, the components should be
exported via namespace quo.core and used by status app only from here. This will
allow a more flexible way to update components without possible breakages into the
app style.
Quo components should and not have any dependency on the status app, this will avoid circular dependency and also benefit the independence of the components.
All components are stored inside components namespaces. They are stateless and do
not dispatch and subscribe to re-frame database. All state should be passed by props
and all events can be passed as functions. Avoiding direct connection with re-frame
will allow components to grow and be reused in different places without the
conditionals hell.
All style system constants are stored inside design-system namespaces. They are used
to build components and can be directly required by the status app. Avoid
duplication of these vars and do not use them in code directly as a value.
For each component introduced, add previews of all possible states.
Do not introduce components for slightly modified existing components, if they are not a part of the design system. In case they are required in one place in the app, use style override.
Code style
Ensure that your changes match the style of the rest of the code. This library uses Clojure Community code style The Clojure Style Guide To ensure consistency run clj-kondo linter
Best practices
- Desing components atomically and compose them into bigger components.
- Do not export individual atoms, only components. This way we can limit design system to be used in too many way which can creating disjointed experiences.
- Avoid external margins for atom components, it can be added on the wrapper where they are used but can't be removed without overriding. Max Stoiber article on margins
- Design reusable components into Layout Isolated Components (Article more relates to web, but ideas fits also to mobile dev**
- Explicit is better than implicit, do not rely on platform default, if you expect a specific value, then override it
TBD:
- Components documentation
- Check props using spec in pre conditions.