pubsweet issueshttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues2020-01-21T15:31:57Zhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/371RFC: lightweight service container2020-01-21T15:31:57ZTamlyn RhodesRFC: lightweight service container## Problem
There are a number of cross-cutting concerns which cannot easily be componentised using the current component system since they need to be used by other components without being referred to by name. So far we have:
- `email`...## Problem
There are a number of cross-cutting concerns which cannot easily be componentised using the current component system since they need to be used by other components without being referred to by name. So far we have:
- `email` - provides a way for components to send email without caring about the underlying delivery mechanism
- `auth` - components need to check authorisation without knowing which authsome mode is being used
- `logger` - components need to log stuff without knowing where it is going
- `file storage` - components need to write and read file data without knowing where it is stored
## Current solutions
Currently we are using a mixture of patterns to achieve this:
- `email` and `auth` - implement the service in a module and put a reference to the module in the app config. This leads to odd-looking code like `const mode = require(config.get('authsome.mode'))`. It's also not clear in the config which values are actually module references.
- `logger` - store the actual service in the config but create a dedicated package for it and expose a method which allows application code to replace this value at runtime and have this change affect all consumers of the service. The first part (non-serialisable objects in config) leads to problems with node-config and the second part (dedicated package per service) is a lot of repeated code.
- `file storage` - doesn't exist yet
## Proposed solution
Create a small wrapper to standardise the way we do this.
Add a section in the config:
```json
"services": {
"server": {
"email": "@pubsweet/aws-ses-mailer",
"auth": "./src/auth/mode.js",
"logger": "winston",
...
},
"client": {
"auth": "./src/auth/mode.js"
}
},
```
Then consume a service like:
```js
const services = require('pubsweet-server/src/services')
const mailer = services('email')
```
or
```js
const services = require('pubsweet-client/src/services')
const authsome = services('auth')
```https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/365Visual regression testing for styleguide2019-02-14T23:31:10ZTamlyn RhodesVisual regression testing for styleguideThis is particularly useful to run locally when refactoring components to check that you haven't accidentally broken anything. It may not make sense to integrate into CI until the components have stabilised a bit.
I got quite far with [...This is particularly useful to run locally when refactoring components to check that you haven't accidentally broken anything. It may not make sense to integrate into CI until the components have stabilised a bit.
I got quite far with [React Styleguide Visual](https://github.com/unindented/react-styleguidist-visual) but there are a [few](https://github.com/unindented/react-styleguidist-visual/issues/13) [issues](https://github.com/unindented/react-styleguidist-visual/issues/14) to resolve.Documentation websitehttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/356Event subsystem (for notifications)2019-12-10T14:42:53ZTamlyn RhodesEvent subsystem (for notifications)PubSweet applications need a way to notify users when certain things occur. For example:
- Author receives an email when their manuscript is approved
- Editor receives a mobile push message when a manuscript is assigned to them
- Peer re...PubSweet applications need a way to notify users when certain things occur. For example:
- Author receives an email when their manuscript is approved
- Editor receives a mobile push message when a manuscript is assigned to them
- Peer reviewer receives a desktop notification when a new message is posted in chat
- Staff dashboard updates to show a new manuscript via a GraphQL subscription
To this end we can create an event bus which receives events from server endpoints/mutations and allows other server components to listen to these and trigger notifications as they see fit.
It's likely that this will be useful beyond just notifications. For example an audit log will be easier to understand if it is structured around user events rather than database updates.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/352Make components AA accessible2018-03-29T12:53:17ZSam GalsonMake components AA accessibleeLife is committed to the AA standard and my guess is (?) Coko will be too. We should probably start to build this in even when we touch components for other purposes.
What is AA? Each of the requirements listed in https://www.w3.org/TR...eLife is committed to the AA standard and my guess is (?) Coko will be too. We should probably start to build this in even when we touch components for other purposes.
What is AA? Each of the requirements listed in https://www.w3.org/TR/WCAG20/ is labelled A, AA or AAA - so it’s all the A and AA ones.
However, the standard is about to be updated with this: https://www.w3.org/TR/WCAG21/.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/349Use a grid library for UI components2018-07-31T16:30:03ZYannis BarlasUse a grid library for UI componentsAs discussed in !101, `grid-styled` is the one to use.As discussed in !101, `grid-styled` is the one to use.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/342Add hooks for custom CSS overrides2021-08-24T08:50:05ZSam GalsonAdd hooks for custom CSS overridesAs agreed at the PubSweetMeet (I think! someone confirm?), requirements for all components are:
* **Every** exported component should render a styled component and every child element of that component should be a styled-component
*...As agreed at the PubSweetMeet (I think! someone confirm?), requirements for all components are:
* **Every** exported component should render a styled component and every child element of that component should be a styled-component
* Every styled component (incl. children) should have a hook for custom CSS
* Overriding subcomponents of a single instance (e.g. an input's label) will be done by passing in CSS with a selector for the subcomponent (rather than wrapping with a new ThemeProvider).
* The hook looks like this, though we should consider ways to refactor similar to the `th` helper:
```
${props => props.theme.css.<package-name>.<component-name>.<subcomponent-name>}
```
* `<package-name>` is the name from package.json stripped of its prefix (@pubsweet or pubsweet-component-*)
* `<component-name>` is the exported component
* `<subcomponent-name>` is the component having the hook applied to it
Outermost components will be referenced like subcomponents, for example: `props.theme.css.ui.Form.Root`, not `props.theme.css.ui.Form`https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/337RFC: Organise styleguide2019-02-14T23:14:14ZSam GalsonRFC: Organise styleguideIf https://gitlab.coko.foundation/pubsweet/pubsweet/issues/336 is accepted we will have only one styleguide for all components. This will need to be better structured than it currently is. Something like this:
* Atoms
1. Input
...If https://gitlab.coko.foundation/pubsweet/pubsweet/issues/336 is accepted we will have only one styleguide for all components. This will need to be better structured than it currently is. Something like this:
* Atoms
1. Input
* Buttons
* Text
* Selects
* Radios
* etc.
2. Display
* Text
* Layout
* Modals
* Spinners
* Headings
* Tables
* etc.
* Molecules
1. File handling
* Uploads
* Attachments
2. Progress tracking
3. Navigation
* AppBar
* Pages
1. User admin
* Login
* Signup
2. Manuscript editing
The idea here is that atoms are abstract, but molecules/pages are likely to relate to specific business concerns.Documentation website