# Web Application Security Checklist Task:

* ***Always split admin front-end on a SPA, the user can tamper component's state and reveal admin views useful for reconnaissance.***
---
### Front-end challenge:

Most of the **same react components** will be used for both user-facing and back-office (admin) UI's., so we need to avoid duplication.

General UI library is required as a single source of truth for the designers, developers and brand managers. Key consideration factors:

* Maintenance
* Pricing
* Testing
* Self-Hosted
* Developer Experience

*Maybe at some point in the future., and we had a brief discussion with Mati about it (a while back). But a comprehensive **Design System** would be very beneficial in the long run. Acting as a base for the creation of themes and styleguide for all of the white label projects!*

*\* Meawhile we can have themes/config generation page in the Admin (Back-Office) which would create all of the required colors, logos, dark and light theme etc., as illustrated below...*

---
### Visual Communication


### So how are we going to manage all these UI components?

#### *Option Nr.1:*

| Software | Maintenance | Pricing | Testing | Self-Hosted|
| -------- | -------- | -------- |------|-----|---|
| [Bit](https://bit.dev/) | None (cloud service) | [See plans](https://bit.dev/pricing) | Yes | No |

**Developer Experience:**

* Played around with this service - set up two projects to see how the [communication](https://docs.bit.dev/docs/quick-start) actually works, *not without hickups* - (when you use TS and a bunch of third-party libraries, dependencies can clash so you need to figure out what goes into peerDependancies etc... and sometimes it's not as straightforward either). It basically acts as **Git** but specifically for components. Their`cli` - is called **Bit** and the rest of the tooling is pretty awesome too! Test suits run in the cloud as well as preview and interaction in the browser.

#### *Option Nr.2:*

| Software | Maintenance | Pricing | Testing | Self-Hosted|
| -------- | -------- | -------- |------|-----|---|
|[NPM](https://www.npmjs.com/)|None (cloud service)|[See plans](https://www.npmjs.com/products)|No|No|

**Developer Experience:**

* This approach could be no brainer for those who are familiar how this all works. But for me it's about productivity and sharing some kind of **logical function** is not exactly as sharing a **UI component**. The questions I had were like:
* Where does one develop the component? In the `project` and then port (copy/pasta) into the library. Push to NPM then replace the component with the one that's been pushed! Where do you run tests? Etc...

* So I have created a minimal **UI Library Boilerplate**! Alows preview and development right in one place also generates NPM package on the fly. [Here is the repository](https://github.com/onepixelcitizen/temp-react-components-npm) and hopefully readme explains the concepts well enough! All POC tests run as well - [https://www.npmjs.com/package/ui-x-library](https://www.npmjs.com/package/ui-x-library)

#### *Option Nr.3:*

| Software | Maintenance | Pricing | Testing | Self-Hosted|
| -------- | -------- | -------- |------|-----|---|
|[Styleguidist](https://react-styleguidist.js.org/)|Low|Open-source|Yes|Yes|

**Developer Experience:**

* Comparing to the likes of [Docz](https://www.docz.site/) or [Storybook](https://storybook.js.org/) - Styleguidist (used on TradeOr) had less TS issues and is pretty good! Storybook (SB) (v 5.0) was also quite painful and required quite a bit of maintenance, something we completely want to avoid. Haven't tested latest SB v5.2 or Docz (which I think had latest react hooks API issues with TS).

* In other words this is more advanced version of my implementation of the UI library but maybe overkill or undesired dependency whereas above we have our own implementation and full control which we can be advanced as we see fit.

**If anyone has other suggestions please share!**