node package manager


CluedIn Widget

This project contains all the pages needed for browsing entities and searching them. The aim is to replace the CluedIn.Webapp project with this one when all the pages ( including the Admin page ) will be ported to REACT.

The project is divided in 2 parts. The first one is the main REACT application and the second all all the widgets to build an Entity Page.

All the widgets are located in the folder 'widget' in the project root.


You need a version of node and npm installed.

Some basic knowledge of React is required.

The main plugins used are: react, react-router, redux, react-intl,...

The project is written in ES6 using Babel and Webpack to generate the APP.

Getting Started

Install dependencies

npm install

Generate the app ( and/or the style )


Run the Web Dev Server ( react hot reloading )

npm run start

Project Structure


Contain the react application.


Contain some scripts needed by the NODE.JS Server ( located in CluedIn.Webapp ) to serve the appropriate static files to the APP or any page ( self-injectable widget ).


All stateless methods which can be used in the browser or in a node environment. If you have a stateless method which looks generic enough, please, add them in the ISO folder.

PS: 'iso' stands for 'isomorphic'.


Contain all the translation for the application used by a plugin called React-intl.

Styling the application

Generic Styling

This project is using SCSS.

The styles are located in the /core/style.

Styling a React component

This project uses React-Css-Module for styling component. This enables us to have self-contained CSS.

Please, refer to for more information.


This project uses Redux for structuring the application.

Create a specific Entity Page

The routing of the app is dynamically generated based on the entity configuration (/core/config/entity.js).

If the entity config object has the parameter 'url' present, the app will create a router for it

If the entity config object does not have the 'url' parameter, the app will use the defaultEntity page


  • Keep React component as generic as possible ( avoid using the Connect method from the Redux library ).
  • Do not hesitate to create React components
  • Favor props over state in your React component. State is generally used by wrapper components
  • Dispatch your (redux) actions in wrapper components
  • Try to keep the style self-contained and favor SCSS mixins and placeholders inside your component scss file
  • If you have small images, leverage Webpack to load them in base64 directly in the application

When shit hits the fan in production:

  • rollback client code using the widget.production value from the package.json of webapp

registering new widget:

  • write your widget
  • register it using registerEntityWidget
  • add you newly created widget to the list of import in 'build/widget.js'

improve testability

  • Have a stable org in test with many stuff.
  • Have an org which has plenty of notification even fake ones.


Cluedin on-premise version. As cluedin is targetting a global market, the Fortune 500 generally wants their cluedin installation to be located on their infrastructure and not on the 'cloud'.

In order to acheive this, we need to update all the F-E projects to support on-premise versions. Please note, for the first version of on-premise, the idea is to 'make it work'. Not to make the perfect version.

Signin-SignUp - Forgot...

For the first version, the F-E version will only support SSO Provider, meaning the login/logout/forgot password will be forwarded to internal system such as a LDAP, an Active Directory and even an Office 365 account. It does not really matter, at this, point as the Cluedin F-E will delegate.


By delegating all the login-logout mechanisms, we simplify the application be removing the following mongoose collection:

  • Invite
  • Invite User
  • Forgot Password
  • SignUp Email Domain

To Validate: make sure you can signup/login with new accounts and that the invite is still probably sending an email. Ideally, if new feature => use the cluedin API (and not the mogo collections).


The CluedIn Layouting is still using a mongoose collection. The collection being used are:

  • customWidget config
  • entityWidget config
  • layout
  • sessions
  • userProfile

All those collections have an incidence on how Cluedin will behave. We need to find a way to make that 'easily' deployable. Ideally, avoid having Mongo DB to be installed for using the Application as it would make the step a bit harder for the customer.

Entity Widget could be loaded before-hand in a JSON file or something 'hard' during the start of the on-premise installation. (Currently it is loaded from Mongo and being store in memory by the server).

It remains to find solutions for Layout, UserProfile and CustomWidgetconfiguration. Layout could also be loaded with a configuration file (nothing heavy that could be generated, loaded in memory and use by the server in on-premise mode).

This leaves us with the 2 last collections: UserProfile and CustomWidgetConfiguration. Those would still be required as it gives the possiblity for the user to 'customize' the Layout/Widgets configuration or to store some user prefernces related to the front-end Application. If we want to avoid the burden of installing Mongo DB on premise, we should probably move those 2 collections to Ms SQL Server.

Update Version

If no changes in the DB => as simply as updating few files in the Product (the main APP).

If changes in the DB => script to migrate them + updating few files in the Products (the main APP) (keep versioning of UI in DB).

Decrease number of dependencies

For on-premise, the less technologies involved and dependencies being chosen, the better as Companies can sometimes have some 'weird' policies.


  • Create Configuration file to bootstrap the Application
    • URL to the API (auth and api) (estimate: 2 days - most of it is existing)
    • URLs for the redirection (as it might not be '' domain) (estimate: 2 days - need to verify)
    • a way to FORCE the client_id of the installation (as this won't run multiple domain) and not assuming it is the subdomain (estimate: 3 days)
    • no more pointing to CDN but to some local instances (estimate: 2 days)
    • the SSO config (or at least the API backend need to provide it) (estimate: 1 day)
  • Probably, move session to Ms SQL to remove one collection in Mongo DB (estimate: 3 days)
  • Probably, move, to start with, the CustomEntityWidgetConfiguration and the UserProfile to Ms SQL using (estimate: 5 days)
  • Divide the product into multiple 'Features' and elaborate if it makes sense to include in the on-premise solution. (estimate: 1 day)
  • Create specifications in order to know what are the CPUs, RAM, so on and so forth for the Node.JS (estimate: 1 day)
  • Create specifications in order to know what are the supported browsers. (estimate: 0 day)
  • Create documentation on how to install the application locally (estimate: 2-3 days with Simona Touch)

Total: 23 days.

For Windows

  1. Install vagrant
  2. Install cgwin make rsync package is checked
  3. vagrant up

Definition of Done

Define what a developer is doing when working on a task in the Cluedin F-E.

    1. Write the code meeting the quality critierias (ESLint)
    1. Write unit tests for the code (ideally TDD)
    1. Each commit should pass the GIT Commit HOOK
    1. Write integration tests for the code (ideally based on a scenarios in Cluedin.Webapp.Integration)
  • 5 do not user magic string, do use translation (react-intl) for any user facing text
    1. Each code pushed in master is deployed to TEST (and the tests are all validated by CI)
  • [in-progress] 7. Explore penetration testing in a Pair Programming mode (and ideally write tests to prove it works).
    1. Before deploying to production, the integration tests should have been executed in SauceLab by the robot.