@associ/groups-frontend

running project in development

To run via docker-compose:

npm start

To run with host node and only infrastructure on docker-compose:

npm run host:dev

Tasks up for grabs

• Make the design responsive
• Error handling on all existing API calls
• Better loading indicator while performing HTTP call
• Smoother transitions when adding comments, posts; removing posts
• Allow tagging. Type @ to start tagging a person. It should be a new type of content block.
  • v2: Make "Respond" work: add tag
• Sticky header with "Læst" action so it is always within reach when viewing a post
• Support more content blocks, like bold and italic text, lists of text, headings
  • for headings: if the very first content block in a post is a heading, move it above the username to give it even more emphasis
• Læst/mark read feature: hvis man selv opretter en post skal den være markeret som læst pr default
  • Hvis man har læst en post og kommenterer på den skal den forblive læst.
• If a post has been read but is being shown because of new comments, show less of the post text (with "Read more...")
• If a post has been read after some comments were added, but is being shown because of new comments, collapse all but the last of the already-read comments.
• Support vedhæftninger
• Support fremhævede vedhæftninger (vis et preview af en eller anden art)
• Support editing of comments and posts
  • We need some way of saving previous versions of a post so they can still be found in future, while updating the "content".
  • This will also introduce a new "updatedAt" timestamp in posts and comments that we should maybe show somewhere in the frontend to indicate an edited post/comment.
  • The edit history of posts and comments should be viewable in the frontend.
• Support highlighting posts, only available to certain users (a role?) which puts it at the very top of every list until it has been read (after which it will be in-order again), including highlighted posts being included in group overviews as full posts rather than just a count
• Support highlighting comments, which does the same for the post but highlighting the comment
• Support notifying users about posts or comments, which can only be done to highlighted posts which immediately results in an email being sent to the users with the contents.
• Poll for updates every x time (maybe latestActivityAfter= filter on calls)
• Pagination/load more posts with latestActivityBefore= filter
• Pagination/load more comments by only showing new posts after last read per default (+ one old one for context?), allow loading later or earlier comments

Search feature

Enriched posts have qualified authors, comments inline, so it might be possible to just index these in elasticsearch - is there a way to listen to changes (add, update, delete) of these direct from mongodb? A separate service should do the sync.

User interface: search input entered should autoauggest keyword searches, each keyword becoming a deleteable (or editable) little block. A block type is also "phrase" (in quotes) and "free text" (fuzzy words). Keywords:

• author (autocomplete with user full name but search for id)
• group: autocomplete with group displayname but search for name
• postCreated{Before,After}
• commentCreated{Before,After}
• activity{Before,After}

Challenge: readAt timestamp so we can do "isRead" queries. Can we do cross-index queries on keys in es?

It will probably be a single service listening to mongodb events and making changes in elasticsearch. Maybe it should just listen and transform each event into a kafka event, and several consumers can then handle them? But I don't know how we would have redundancy in listening on mongodb while deduping the results.

Cleanup: To ensure a clean index long-term we should have cleaning jobs regularly scheduled.

• Remover: elasticsearch scan-and-read allows to read all items one at a time. We can check each entry and see if it still exists in mongodb, and if not, remove it from elasticsearch.
• Reindexer: do a full read of the mongodb entries and put current state for each item in elasticsearch (ensures lagging updates, creates). Both of these services could be batched and parallelized if needed, with different intervals on posts of different ages, so more recent posts are reindexed more often. If cleanup finds anything to clean up that means mongoevents are unstable. Good metrics on how trustworthy that connection is/how often cleanup should run

Could be generalized! Config for sync services is just mongo collection -> es index mapping