| Attribute | Description |
--------|--------------
className | Adds custom class name to marker. All markers have class name stx-marker.
x | x position of the chart; depends on xPositioner.
xPositioner | Determines x position. Choose between epoch or none. Defaults to epoch.
y | y position of the chart; depends on yPositioner.
yPositioner | Determines y position. Choose between value or none. Defaults to value.

There are more options for xPositioner and yPositioner in ChartIQ docs. What we document here is the most common use case.

#### Marker API

Use FastMarker to render given Components under stx-subholder.
It will keep the marker position on the chart.

`jsx
markerRef={setRef}
threshold={optional visibility threshold}
className="your-css-class"
>



`

USAGE:

- setRef({setPosition, div}) will be called onMount.
- setRef(null) will be called when the marker unmounts.
- div is the dom element containing the marker with your-css-class
- any content update should be done using div and vanilla js
- use div.querySelector('...') to get a dom reference in order to update your content.
- avoid doning expensive DOM operations on div such as style changes.
- setPosition({epoch, price}) is a function that you will use to update the div position.
- epoch is the tick unix epoch from api
- price is the tick price, it could be null if you want to draw a vertical line.
- call setPosition({epoch: null, price: null}) to hide the marker.


PROPS:
- threshold (optional): the chart has a zoom level, the marker will be only shown within that threshold.
- markerRef (required): pass the setRef callback using this property
- className (optional): avoid expoensive css transition or keyframe animations on this class.

$3

- epoch_array: array of epoch values to get coordinates for.
- draw_callback: called on every frame with ({ctx, points}).
- points will be an array of [{left, top, epoch}] in pixels.
- ctx is the Context2dDrawingContext

$3

We offer library users full control on deciding which of the top widgets and chart control buttons to be displayed by overriding the render methods themselves. To do this you pass in a function to chartControlsWidgets or topWidgets.

For example, we want to remove all the chart control buttons, and for top widgets to just show the comparison list (refer app/index.jsx):

`jsx
import { ComparisonList } from '@binary-com/smartcharts';

const renderTopWidgets = () => (



Here are the following components you can import:
- Top widgets:
- {}} />
-
-
- Chart controls:
-
- {}} />
-
-
-
-
-
- {}} />
-
-

### Props vs UI

Certain chart parameters can be set either by props or from the chart UI:

- symbol - set by
- granularity - set by
- chartType - set by

This creates conflicts in deciding which is the single source of truth. To circumvent this, if these props are set (not undefined), selecting options in its corresponding components will not have any affect on the chart; the prop values take precedence. To have control over both the UI and the props, we provide library users the option to _override_ component behaviour via onChange prop. For example, to retrieve the symbol a client chooses:

`jsx
onChange={(symbol) => { / ...Pass to symbol prop in / }}
/>
`

See available components and their props in Customising Components.



Contribute

To contribute to SmartCharts, fork this project and checkout the dev branch. When adding features or performing bug fixes, it is recommended you make a separate branch off dev. Prior to sending pull requests, make sure all unit tests passed:

yarn test

Once your changes have been merged to dev, it will immediately deployed to charts.binary.com/beta.

Developer Notes

$3

We organise the development in Trello. Here is the standard workflow of how a feature/bug fix is added:

1. When an issue/feature is raised, it is added to Backlog list. For each card added, it should have a "QA Checklist" (Add checklist to card) for QA to verify that the feature/bug fix has been successfully implemented.
2. In a meeting, if feature/bug fix is set to be completed for next release, it will be labeled as Next Release and placed in Bugs/Todo list.
3. Cards are assigned to developers by adding them to the card; manager gets added to every card.
4. If a developer is actively working on a card, he places the card in In Development; otherwise it should be placed back into Bugs/Todo list.
5. Once the feature/bug fix is implemented, the developer needs put 2 things in the card before placing his card in Review list.:
- PR: Link to the PR.
- Test Link: Link to github pages that has the changes; this is for QA to verify. Refer to this section for instructions on how to deploy.
6. If reviewer requests changes, he will place the card back to the In Development list. This back and forth continues until the reviewer passes the PR by marking it as approved in Github.
7. Reviewer places the reviewed card into QA list.
8. If the card fails QA check, QA can comment on the card on what failed, and place the card back to In Development list. If QA passes the changes, QA will place the card from QA to Ready; this card is now ready to be merged to dev.
9. Once the card is merged to dev, it is placed in Deployed to BETA list.
10. When it is time to take all changes in beta and deploy in production, manager will merge dev into master, and place all cards in Deployed to BETA to Released.

$3

Some issues only show up for library users, so it is helpful to test the NPM package before deploying it to library users. You can do this by building the library directly into the node_modules directory of an app that uses the SmartCharts library. For example to test the library build on binary-static you can execute:

yarn watch --output-path '../binary-static/node_modules/@binary-com/smartcharts/dist'

Now each time you make any change, it will overwrite the SmartCharts library inside the node_modules folder.

$3

There should be a clear distinction between developing for app and developing for library. Library source code is all inside src folder, whereas app source code is inside app.

Webpack determines whether to build an app or library depending on whether an environment variable BUILD_MODE is set to app. Setting this variable switches the entry point of the project (app build mode uses app/index.jsx while library uses src/index.js). We do it this way to develop the app to have hot reload available when we modify library files.

$3

All strings that need to be translated must be inside t.translate():

`js
t.translate('[currency] [amount] payout if the last tick.', {
currency: 'USD',
amount: 43.12
});
t.setLanguage('fr'); // components need to be rerendered for changes to take affect
`

Each time a new translation string is added to the code, you need to update the messages.pot via:

yarn translations

Once the new messages.pot is merged into the dev branch, it will automatically be updated in CrowdIn. You should expect to see a PR with the title New Crowdin translations
in a few minutes; this PR will update the *.po files.

### Dealing With SVGs

SmartCharts has 2 ways of utilizing SVG files: as CSS background image and as external SVG.

##### CSS Background Image SVG

These SVG are added inline into the CSS via postcss-inline-svg. Currently the only place where this is used is the loader, because if the external SVG is not loaded yet we would at least want a loading screen to be present.

##### External SVG

The SVG files included in the js and jsx files are automatically put together into a sprite sheet. Manipulating external SVG can be tricky - developers can only control stroke and fill color of the whole SVG file via CSS:

`scss
.ic-icon.active {
svg {
stroke: #2e8836;
fill: #ff3d38;
}
}
`

Important Note: These stroke and fill colors will not be affected by CSS if the corresponding attributes are declared in the SVG file. Therefore, it is not uncommon SmartCharts developers would need to tweak the SVG files by hand to be able to manipulate its color.

This has much less freedom compared to inline SVG where a developer can control individual parts of the SVG, but having external SVG results in a much smaller library, and allows parts of the code not rendered by React to use them. External SVG is also cached by the browser (using shadow DOM), so though the same SVG may be used multiple times, only one copy exists in the DOM.


### State Management and the connect Method

SmartCharts uses a variation of Mobdux to assist with state management using Mobx.

Each component consists of 2 parts: a template (.jsx file), and a store (Store.js file). There are 3 scenarios in which the connect method is used:

##### 1. Main Components: The component is tied directly to the main store.

Examples: , , ...

Each component here is mapped to a corresponding store in the main store. Only one copy of this component may exist per instance, and its state is managed by the main store tree (defined as mainStore in SmartCharts). Here you pass a mapperFunction that would be applied directly to the main store:

`jsx

function mapperFunction(mainStore) {
return {
value: mainStore.subStore.value,
}
}

export default connect(mapperFunction)(MyComponent);
`

Connections in the scenario #1 should be done in the jsx file, to keep consistent with other components. Except for the component tied to the main store (Chart.jsx), all components using this method should be SFC (Stateless Functional Components), and have the lifecycle managed by the main store.

##### 2. Subcomponents: Component is connected inside a store

Examples: