Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bottom Tab with initial screens #2

Merged
merged 32 commits into from
Feb 18, 2025
Merged

Bottom Tab with initial screens #2

merged 32 commits into from
Feb 18, 2025

Conversation

CassioMG
Copy link
Contributor

@CassioMG CassioMG commented Feb 13, 2025

This PR creates a folder structure along with a initial rough version for the Bottom Tab with 4 tabs: Home, Swap, History and Settings. It also includes Login and Sign out buttons along with a network detector which displays a No internet connection banner.

This PR also ports the Button component from SDS to react-native along with its corresponding Button/theme.ts file also ported from SDS.

Also included in this PR:

  • Rename project from FreighterMobile to freighter-mobile for naming consistency across other stellar projects
  • Add styled-components for UI styling
  • Add initial redux store and reducer
  • Add initial navigators and routes
  • Add BaseLayout component that should be used to wrap all screens
  • Add a dimensions helper to automatically resize components, fonts and spacing based on device screen size
  • Add a debug helper for better dev experience
  • Port global theme values from SDS
Screen.Recording.2025-02-12.at.17.02.16.mov
Screenshot 2025-02-12 at 17 20 38

@@ -0,0 +1,19 @@
export const COLORS = {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it would make sense to try to get close to the conventions in the SDS?
Like making primary/secondary/etc identifiers at a global level and having primitives for font size/weight, etc.

Example - https://github.com/stellar/stellar-design-system/blob/main/%40stellar/design-system/src/theme.scss#L360

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great idea, I'll port over this theme file to the project

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Use throughout your app instead of plain `useDispatch` and `useSelector`
export const useDispatch = () => useReduxDispatch<Dispatch>();
export const useSelector: TypedUseSelectorHook<RootState> = useReduxSelector;
export const useStore = () => useReduxStore<Store>();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cassio and I talked about this briefly over DM, but we may want to consider sharing reducers between extension and mobile. It would be nice to be dealing with the the same actions and similarly shaped data when retrieving account info, for example

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bringing this up. I think having similarly shaped data would be nice and could be helpful with code/logic understanding between the 2 products. But I'm also a bit worried that it could get in the way sometimes, since web and mobile have their differences as well. I'd say we could try mimicking each other whenever possible as a suggested approach but also have the flexibility to diverge from each other. Wdyt?

when retrieving account info, for example

@piyalbasu would you mind linking here the extension actions for retrieving account info that you have in mind so we could take a look as an example?

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can keep discussing it offline and also during the next PRs, I'll merge this one now so we can keep moving! :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I'd lean to not do this so we don't inherit the store patterns we have in Freighter today, we've had trouble getting the desired UX out of the usage of our store in the past and are currently refactoring some big parts of the store away from it and into hooks(history/balances).

@CassioMG CassioMG merged commit 9760171 into main Feb 18, 2025
2 checks passed
@CassioMG CassioMG deleted the cg-setup-folders branch February 18, 2025 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants