stop automatic grouping of repo events by identifer and
earliest unique commit into a single collection.
allow selection of different repos that have an
identifier collision by prioritising pubkey:identifier
over identifer
show repos grouped by name
store hexpubkey in Repo and Proposal data object
instead of full profile
this prevents unnecessary state updates for those objects
the trade-off is including business logic (getting profile data)
within UI components
this is mitigated by allowing hexpubkey or UserObject to be passed
to UI components so that UI component tests can be written without
having to worry about business logic
this new approach can be abstracted to other object types
prevent non-root patches from displaying on homepage where possible
via client side filter for non-root patches on repositories
that support the latest nip34 spec
on repository pages this is included in the relay subscription but when
we are getting patches for all repositories, like on the homepage,
we don't know ahead of time which ones support the latest spec
this doesnt apply to subscriptions that we for many types simultainiously
ie repos and users
also extend limit from 50 to 100. if we need to go higher,
will we need to introduce a system to get around relay limits?
choose repo events based from earliest_unique_commit and indentifier
based on:
- number of mentions (issues and root patches)
- most recent created_at
identify repo events for the same repository based on identical identifiers
and use of earliest_unique_commit
use stores for collections of repo events
with nip34 in its current state there is no way to identify the root
patch without first requesting all patches and client side filtering
out the ones with `[ PATCH n/n ]` in
the content
this commit doesn't do that filtering
prevent bug where PR responses and summaries are added to an incorrect
pr or repo after the array has been cleared but before
ensureSelectedRepo has returned