App Review Guidelines

• Think twice before introducing state of any kind. Is this really new state, or is it actually state that can be derived from other state? Ensure that there is always only one source of truth for any kind of data. use Svelte's derived for derived state.
• Do not use $: syntax. It makes it very hard to reason about what triggers an update of a derived value, making it error prone. It has also been removed completely in Svelte 5.
• DRY: Do not copy-paste code
• Try to break your PR. Before marking a PR as "ready for review", really try to break it. connect/disconnect wallets. change url params, spam-click buttons, etc. Try to break the app.
• Before marking a PR as ready for review, ensure that it looks correct on every possible screen size, in both light and dark mode.
• In order to keep PRs reviewable, put dependency changes in separate PRs.
• Do not use my/px-auto to align items. Instead, use flexbox for alignment.
• Do not use inlined hardcoded colors. Instead, only use colors from the tailwind theme. If you need a new color, then add it to the theme. The only exception is elements that are in the style of third parties.
• Do not override component styles, other than for minor adjustments that only apply to this specific instance. The point of components is to ensure consistent styling. If you override the component's styling everywhere, then that defeats the purpose of having a component library in the first place.
• If none of the provided variants for a component (such as the buttonVariants) suit your needs, then add a new one.
• Whenever bumping dependencies, double check all app functionality to ensure that nothing has changed.
• Prefer putting components in $lib/components. Putting components in routes/ makes it very painful to refactor items and put them on other pages. Putting components in $lib/components also makes it more obvious if similar components are defined multiple times for different pages. It also helps you consider how you can define reusable components.