Import services methods in object rather than separately

[pmarsh-scottlogic]

Description

In the frontend we now import service methods like import * as someService from '@src/service/someService' then do someService.serviceMethod() in the code.

This is to clear up the many instances of confusing code like

function addInfoMessage(message: string) {
    addChatMessage({
        message,
        type: 'GENERIC_INFO',
    });
    // asynchronously add message to chat history
    void addInfoMessageToChatHistory(message, 'GENERIC_INFO', currentLevel);
}

where it is not clear what things will call the api and which things are only doing things in the frontend.

Concerns

• I imagine this comes at a minor performance cost, but I think the readability is worth it
• I wonder if there is a way to enforce that we import from our services like this, so that we are sure we will do it consistently in the future.

Checklist

Have you done the following?

• [ ] Linked the relevant Issue (no issue)
• [ ] Added tests (no functional change. Not worth testing)
• [x] Ensured the workflow steps are passing

[chriswilty]

I wonder if there is a way to enforce that we import from our services like this

There is, kind of: use an index.ts file in @src/service, and inside that put e.g.

import * as chatService from './chatService';
import * as configService from './configService';

export {
  chatService,
  configService,
}

Then you would import your services from the directory:

import { chatService } from '@src/service';

You can enforce directory-level imports in eslint config, if I recall, but we're not ready for that yet as we'd need index files throughout our codebase. That was on my (distant) todo list at some stage.