This document introduces the coding styles and guidelines, development tips, and resources for new contributors to Hawtio.next.
Feedback and suggestions for improvements are always welcome.
- Follow the Conventional Commits for Git commit messages.
- Minimise dependencies to 3rd-party libraries as much as possible for reducing the impact of CVEs.
- Do not use Lodash/Underscore. Always check You don't need Lodash/Underscore.
- Use ESLint and typescript-eslint for more detailed code styling.
The main task of this project is to migrate legacy Hawtio v2 TypeScript code to PatternFly v4 + React.
The basic logic can be used as is, but the legacy Hawtio contains unnecessary code from years of development and it is not desirable to inherit them as they are. Therefore, we need to scrutinise them and migrate only what are really necessary.
The legacy Hawtio follows this AngularJS style guide. Each component is structured based on MVC, with the model being plain TypeScript code, the controller being an AngularJS controller and the view corresponding to HTML. The parts that communicate with the server side are implemented as AngularJS services.
In Hawtio.next, controllers and views are implemented as React components. Models and services are implemented in plain TypeScript. The services are guaranteed to be singleton through the ES Modules import mechanism.
Therefore, the migration from legacy Hawtio to Hawtio.next is basically a process of rewriting the AngularJS controllers and HTML to React components and AngularJS services to plain-TypeScript service classes.
To give one example, the Attributes feature of the JMX plugin is mapped as follows.
MVC | Legacy Hawtio | Hawtio.next |
---|---|---|
Controller & view | attributes.controller.ts attributes.html |
Attributes.tsx |
Service | attributes.service.ts | attribute-service.ts |
Choose FunctionalComponent
as much as possible for implementing a React component. Use React hooks for managing view states and side effects.
The current implementation guidelines are as follows:
- Create one React context per plugin and convey common states and setters from the context within the plugin instead of propagating properties across sub components.
- Example: src/hawtio/plugins/jmx/context.ts
- Don't use React reducers as I find it as a bit too much for Hawtio. Hawtio doesn't need to manage complex client-side states other than one huge JMX tree. (We can revisit this rule anytime if we find it the other way around.)
Refer to the following issues:
- E2E testing strategy #16
- E2E - Run the E2E suite from Hawtio standalone project directly with hawtio-next #322
There are a few supporting projects that Hawtio.next is based on. Although not so frequent, we will still occasionally need to update the projects.
https://github.com/jolokia/jolokia/tree/2.0/client/javascript
The official Jolokia JavaScript client library that also provides type definitions. If there are any issues with jolokia.js
we should raise an issue and contribute a pull request to Jolokia project.
https://github.com/hawtio/hawtio-backend-middleware
The Express middleware that is used in the Webpack dev server and serves as a development-time mock for the Hawtio backend, which enables local development with yarn start
for Hawtio.next.
Let's use GitHub Issues for communications including questions, discussing features, and bug reports.
https://github.com/hawtio/hawtio-next/issues
- PatternFly v4 Components: https://www.patternfly.org/v4/
- You don't need Lodash/Underscore: https://you-dont-need.github.io/You-Dont-Need-Lodash-Underscore/