A web client for Matrix used to replace WhatsApp https://riot.opencloud.lu/
 
 
 
 
Go to file
Travis Ralston 35c9dce241 Fix browser navigation not working between /home, /login, /register, etc
All of the anchors were pointed at `#` which, when clicked, would trigger a hash change in the browser. This change races the change made by the screen handling where the screen handling ends up losing. Because the hash is then tracked as empty rather than `#/login` (for example), the state machine considers future changes as no-ops and doesn't do anything with them.

By using `preventDefault` and `stopPropagation` on the anchor click events, we prevent the browser from automatically going to an empty hash, which then means the screen handling isn't racing the browser, and the hash change state machine doesn't no-op.

After applying that fix, going between pages worked great unless you were going from /login to /home. This is because the MatrixChat state machine was now out of sync (a `view` of `LOGIN` but a `page` of `HomePage` - an invalid state). All we have to do here is ensure the right view is used when navigating to the homepage. 

Fixes https://github.com/vector-im/riot-web/issues/4061

Note: the concerns in 4061 about logging out upon entering the view appear to have been solved. Navigating to the login page doesn't obliterate your session, at least in my testing.
2019-01-03 12:13:41 -07:00
docs
res Fix merge 2019-01-03 18:05:38 +00:00
scripts Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
src Fix browser navigation not working between /home, /login, /register, etc 2019-01-03 12:13:41 -07:00
test Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
.babelrc
.editorconfig
.eslintignore
.eslintignore.errorfiles
.eslintrc.js Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
.flowconfig
.gitignore
.travis-test-riot.sh
.travis.yml
CHANGELOG.md Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
CONTRIBUTING.rst Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
LICENSE
README.md Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
code_style.md Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
header
jenkins.sh Let's use a version of node we can download rather than dig up 2018-11-21 18:53:18 +00:00
karma.conf.js
package.json Partial merge of develop to experimental 2019-01-03 15:02:58 +00:00
release.sh

README.md

matrix-react-sdk

This is a react-based SDK for inserting a Matrix chat/voip client into a web page.

This package provides the React components needed to build a Matrix web client using React. It is not useable in isolation, and instead must must be used from a 'skin'. A skin provides:

  • Customised implementations of presentation components.
  • Custom CSS
  • The containing application
  • Zero or more 'modules' containing non-UI functionality

As of Aug 2018, the only skin that exists is vector-im/riot-web; it and matrix-org/matrix-react-sdk should effectively be considered as a single project (for instance, matrix-react-sdk bugs are currently filed against vector-im/riot-web rather than this project).

Translation Status

Translation status

Developer Guide

Platform Targets:

All code lands on the develop branch - master is only used for stable releases. Please file PRs against develop!!

Please follow the standard Matrix contributor's guide: https://github.com/matrix-org/synapse/tree/master/CONTRIBUTING.rst

Please follow the Matrix JS/React code style as per: https://github.com/matrix-org/matrix-react-sdk/blob/master/code_style.md

Code should be committed as follows:

React components in matrix-react-sdk are come in two different flavours: 'structures' and 'views'. Structures are stateful components which handle the more complicated business logic of the app, delegating their actual presentation rendering to stateless 'view' components. For instance, the RoomView component that orchestrates the act of visualising the contents of a given Matrix chat room tracks lots of state for its child components which it passes into them for visual rendering via props.

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:

  • Components are named with upper camel case (e.g. views/rooms/EventTile.js)

  • They are organised in a typically two-level hierarchy - first whether the component is a view or a structure, and then a broad functional grouping (e.g. 'rooms' here)

  • After creating a new component you must run npm run reskindex to regenerate the component-index.js for the SDK (used in future for skinning)

  • The view's CSS file MUST have the same name (e.g. view/rooms/MessageTile.css). CSS for matrix-react-sdk currently resides in https://github.com/vector-im/riot-web/tree/master/src/skins/vector/css/matrix-react-sdk.

  • 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

  • Theme specific CSS & resources: https://github.com/matrix-org/matrix-react-sdk/tree/master/res/themes structural components (lacking presentation logic) and the simplest view components.

  • 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. In future we'll start using css-next to pull in features like CSS variable support.

  • The CSS for a component can 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.

Originally matrix-react-sdk followed the Atomic design pattern as per http://patternlab.io to try to encourage a modular architecture. However, we found that the grouping of components into atoms/molecules/organisms made them harder to find relative to a functional split, and didn't emphasise the distinction between 'structural' and 'view' components, so we backed away from it.

Github Issues

All issues should be filed under https://github.com/vector-im/riot-web/issues for now.