prepare for storification

[dskvr]

rationale

• svelte patterns
• performance
• maintenance
• lower bar for contribution

why not do this from the start I like strong separation of concerns during alpha, and specifically when the alpha is a proof of concept. This particular alpha was proving specific concepts that that nothing to do with UI/UX or svelte. Removing svelte from the equation significantly reduced lead time for (in)validation. Now that the concept is validated, beta is on the roadmap, which means this is necessary. I kept this particular issue in mind during development, so this issue should take 1, maybe 2 days to complete.

new stores

• ControlFlowStore
• ConfigStore: stores site config

migrated stores/contexts

• $MRP.$.ndk - :context Ndk
• $MRP.$.signal -> :context Signal ... Signal (emitter) will remain for control-flow concerns and editor reactivity, everything else will rely on svelte state management as it should.
• $MRP.nostr.relay -> RelayStore
• $MRP.nostr.owner -> OperatorStore
• $MRP.nostr.owner.feed && MRPFeed instances -> FeedStore
• NoteStore
• $MRP.nostr.user -> CurrentUserStore
• $MRP.nostr.user.profile &* $MRP.nostr.owner.profile && $MRP.nostr.user.follows[*].profile -> ProfileStore

component level

• MRPFeed: class store moved to component level writable (no context keys), class becomes utility that extends fetchers for filter generation, filter/event validation and sanitization.
• MRPUser: ^^^

remains core class for utility

• MRPFeed: fetchers remain
• MRPUser: fetchers remain
• MRPData: extendable class that wraps emitter for stage/status tracking (unchanged)

new generics

• MRPFetchers: extendable fetcher generic.

removed classes

• MRPEditor: data

controlflow

• MRP, MRP.nostr and MRP.nostr.relay control flow logic coalesced into singleton and persisted in ControlFlow store.