148 lines
7.3 KiB
Markdown
148 lines
7.3 KiB
Markdown
matrix-react-sdk
|
|
================
|
|
|
|
This is a react-based SDK for inserting a Matrix chat/voip client into a web page.
|
|
|
|
This package provides the logic and 'controller' parts for the UI components. This
|
|
forms one part of a complete matrix client, but it not useable in isolation. It
|
|
must be used from a 'skin'. A skin provides:
|
|
* The HTML for the UI components (in the form of React `render` methods)
|
|
* The CSS for this HTML
|
|
* The containing application
|
|
* Zero or more 'modules' containing non-UI functionality
|
|
|
|
Skins are modules are exported from such a package in the `lib` directory.
|
|
`lib/skins` contains one directory per-skin, named after the skin, and the
|
|
`modules` directory contains modules as their javascript files.
|
|
|
|
A basic skin is provided in the matrix-react-skin package. This also contains
|
|
a minimal application that instantiates the basic skin making a working matrix
|
|
client.
|
|
|
|
You can use matrix-react-sdk directly, but to do this you would have to provide
|
|
'views' for each UI component. To get started quickly, use matrix-react-skin.
|
|
|
|
How to customise the SDK
|
|
========================
|
|
|
|
The SDK formerly used the 'atomic' design pattern as seen at http://patternlab.io to
|
|
encourage a very modular and reusable architecture, making it easy to
|
|
customise and use UI widgets independently of the rest of the SDK and your app.
|
|
|
|
So unfortunately at the moment this document does not describe how to customize your UI!
|
|
|
|
###This is the old description for the atomic design pattern:
|
|
|
|
In practice this means:
|
|
|
|
* The UI of the app is strictly split up into a hierarchy of components.
|
|
|
|
* Each component has its own:
|
|
* View object defined as a React javascript class containing embedded
|
|
HTML expressed in React's JSX notation.
|
|
* CSS file, which defines the styling specific to that component.
|
|
|
|
* Components are loosely grouped into the 5 levels outlined by atomic design:
|
|
* atoms: fundamental building blocks (e.g. a timestamp tag)
|
|
* molecules: "group of atoms which functions together as a unit"
|
|
(e.g. a message in a chat timeline)
|
|
* organisms: "groups of molecules (and atoms) which form a distinct section
|
|
of a UI" (e.g. a view of a chat room)
|
|
* templates: "a reusable configuration of organisms" - used to combine and
|
|
style organisms into a well-defined global look and feel
|
|
* pages: specific instances of templates.
|
|
|
|
Good separation between the components is maintained by adopting various best
|
|
practices that anyone working with the SDK needs to be be aware of and uphold:
|
|
|
|
* Views are named with upper camel case (e.g. molecules/MessageTile.js)
|
|
|
|
* The view's CSS file MUST have the same name (e.g. molecules/MessageTile.css)
|
|
|
|
* Per-view CSS is optional - it could choose to inherit all its styling from
|
|
the context of the rest of the app, although this is unusual for any but
|
|
the simplest atoms and molecules.
|
|
|
|
* The view MUST *only* refer to the CSS rules defined in its own CSS file.
|
|
'Stealing' styling information from other components (including parents)
|
|
is not cool, as it breaks the independence of the components.
|
|
|
|
* CSS classes are named with an app-specific namespacing prefix to try to avoid
|
|
CSS collisions. The base skin shipped by Matrix.org with the matrix-react-sdk
|
|
uses the naming prefix "mx_". A company called Yoyodyne Inc might use a
|
|
prefix like "yy_" for its app-specific classes.
|
|
|
|
* CSS classes use upper camel case when they describe React components - e.g.
|
|
.mx_MessageTile is the selector for the CSS applied to a MessageTile view.
|
|
|
|
* CSS classes for DOM elements within a view which aren't components are named
|
|
by appending a lower camel case identifier to the view's class name - e.g.
|
|
.mx_MessageTile_randomDiv is how you'd name the class of an arbitrary div
|
|
within the MessageTile view.
|
|
|
|
* We deliberately use vanilla CSS 3.0 to avoid adding any more magic
|
|
dependencies into the mix than we already have. App developers are welcome
|
|
to use whatever floats their boat however.
|
|
|
|
* The CSS for a component can however override the rules for child components.
|
|
For instance, .mx_RoomList .mx_RoomTile {} would be the selector to override
|
|
styles of RoomTiles when viewed in the context of a RoomList view.
|
|
Overrides *must* be scoped to the View's CSS class - i.e. don't just define
|
|
.mx_RoomTile {} in RoomList.css - only RoomTile.css is allowed to define its
|
|
own CSS. Instead, say .mx_RoomList .mx_RoomTile {} to scope the override
|
|
only to the context of RoomList views. N.B. overrides should be relatively
|
|
rare as in general CSS inheritence should be enough.
|
|
|
|
* Components should render only within the bounding box of their outermost DOM
|
|
element. Page-absolute positioning and negative CSS margins and similar are
|
|
generally not cool and stop the component from being reused easily in
|
|
different places.
|
|
|
|
* We don't use the atomify library itself, as React already provides most
|
|
of the modularity requirements it brings to the table.
|
|
|
|
With all this in mind, here's how you go about skinning the react SDK UI
|
|
components to embed a Matrix client into your app:
|
|
|
|
* Create a new NPM project. Be sure to directly depend on react, (otherwise
|
|
you can end up with two copies of react).
|
|
* Create an index.js file that sets up react. Add require statements for
|
|
React and matrix-react-sdk. Load a skin using the 'loadSkin' method on the
|
|
SDK and call Render. This can be a skin provided by a separate package or
|
|
a skin in the same package.
|
|
* Add a way to build your project: we suggest copying the scripts block
|
|
from matrix-react-skin (which uses babel and webpack). You could use
|
|
different tools but remember that at least the skins and modules of
|
|
your project should end up in plain (ie. non ES6, non JSX) javascript in
|
|
the lib directory at the end of the build process, as well as any
|
|
packaging that you might do.
|
|
* Create an index.html file pulling in your compiled javascript and the
|
|
CSS bundle from the skin you use. For now, you'll also need to manually
|
|
import CSS from any skins that your skin inherts from.
|
|
|
|
To Create Your Own Skin
|
|
=======================
|
|
To actually change the look of a skin, you can create a base skin (which
|
|
does not use views from any other skin) or you can make a derived skin.
|
|
Note that derived skins are currently experimental: for example, the CSS
|
|
from the skins it is based on will not be automatically included.
|
|
|
|
To make a skin, create React classes for any custom components you wish to add
|
|
in a skin within `src/skins/<skin name>`. These can be based off the files in
|
|
`views` in the `matrix-react-skin` package, modifying the require() statement
|
|
appropriately.
|
|
|
|
If you make a derived skin, you only need copy the files you wish to customise.
|
|
|
|
Once you've made all your view files, you need to make a `skinfo.json`. This
|
|
contains all the metadata for a skin. This is a JSON file with, currently, a
|
|
single key, 'baseSkin'. Set this to the empty string if your skin is a base skin,
|
|
or for a derived skin, set it to the path of your base skin's skinfo.json file, as
|
|
you would use in a require call.
|
|
|
|
Now you have the basis of a skin, you need to generate a skindex.json file. The
|
|
`reskindex.js` tool in matrix-react-sdk does this for you. It is suggested that
|
|
you add an npm script to run this, as in matrix-react-skin.
|
|
|
|
For more specific detail on any of these steps, look at matrix-react-skin.
|