widget-matches-listing v1.0.2

Widget - Odds listing

This widget describe Odds listing.

Requirements

• node ^5.0.0
• yarn ^0.23.0 or npm ^3.0.0

Installation

After confirming that your environment meets the above requirements, you can clone the project by doing the following:

$ git clone git@bitbucket.org:sportal-media-platform/widget-odds.git <my-project-name>
$ cd <my-project-name>

When that's done, install the project dependencies. It is recommended that you use Yarn for deterministic dependency management, but npm install will suffice.

$ yarn  # Install project dependencies (or `npm install`)

Bind the widget to HTML DOM

You can bind the widget to the HTML DOM by two ways:

• Bind the widget without initial options. The required attribute here is "data-widgetId"

    <div data-widgetId="odds-listing"></div>

• Bind the widget with initial options. The all available options can be seen below

    <div data-widgetId="odds-listing" data-options='{...}'></div>

• The optional "data-options" attribute:

    {
        string lang,      // the language in format like: en, bg, ru and etc.
        string theme,     // Brand theme  
        int eventId,      // Unique identifier of the resource.
        string expand,    // Specifies additional information to include with the Team response
        string oddClient, // Identifies the client for which to return filtered bookmakers with affiliate URLs. Without the parameter can not sort odd_providers or provide affiliate links. Instead it will sometimes give a 'coupon' key with the odds fo building URLs. header
    }

Running the Project

After completing the installation step, you're ready to start the project!

$ yarn run start:dev  # Start the development server (or `npm run start:dev`)

While developing, you will probably rely mostly on yarn run start:dev; however, there are additional scripts at your disposal:

Project Structure

The project structure presented in this boilerplate is fractal, where functionality is grouped primarily by feature rather than file type. This structure is only meant to serve as a guide, it is by no means prescriptive. That said, it aims to represent generally accepted guidelines and patterns for building scalable applications. If you wish to read more about this pattern, please check out this awesome writeup by Justin Greenberg.

.
├── build                            # All build-related code
├── dist                             # The all production-ready code 
├── lib                              # The library source code localization
├── design                           # Static folder where is stored the design (not imported anywhere in source code)
├── src                              # Application source code
│   ├── dev                          # Application bootstrap and rendering
│       ├── Main.jsx                 # The entry point of App (bootstraping component)
│       ├── Index.html               # Static HTML template (It is using only in dev mode ) 
│   ├── lib                          # Application widget where will live
|       ├── components               # The all sub-components where will be stored
|       ├── OddsListingComponent.css # The widget styles
|       ├── OddsListingComponent.jsxsx # The widget component
│   ├── styles                       # Application styles where will live
└── tests                            # Unit tests

Live Development

Hot Reloading

Hot reloading is enabled by default when the application is running in development mode (yarn run start:dev). This feature is implemented with webpack's Hot Module Replacement capabilities, where code updates can be injected to the application while it's running, no full reload required. Here's how it works:

• For JavaScript modules, a code change will trigger the application to re-render from the top of the tree. Global state is preserved, but any local component state is reset. This differs from React Hot Loader, but we've found that performing a full re-render helps avoid subtle bugs caused by RHL patching.

Testing

To add a unit test, create a .spec.js file anywhere inside of ./tests. // TBD

dirty-chai

Some of the assertions available from chai use magical getters. These are problematic for a few reasons:

1) If you mistype a property name (e.g. expect(false).to.be.tru) then the expression evaluates to undefined, the magical getter on the true is never run, and so your test silently passes. 2) By default, linters don't understand them and therefore mark them as unused expressions, which can be annoying.

Dirty Chai fixes this by converting these getters into callable functions. This way, if mistype an assertion, our attempt to invoke it will throw due to the property being undefined.

// This silently passes because the getter on `true` is never invoked!
it('should be true', () => {
  expect(false).to.be.true() // evalutes to undefined :(
})

// Much better! Our assertion is invalid, so it throws rather than implicitly passing.
it('should be true', () => {
  expect(false).to.be.true() // `tru` is not defined!
})

Building for Production

Deployment

Out of the box, this widget is deployable by serving the ./dist folder generated by yarn build:prod.