Skip to content

Latest commit

 

History

History
87 lines (52 loc) · 5.15 KB

developing.md

File metadata and controls

87 lines (52 loc) · 5.15 KB

Developing Hawtio.next

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.

Styles, conventions, and guidelines

How to migrate legacy Hawtio code

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.

Mapping between legacy Hawtio and Hawtio.next

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.

Mapping example

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

Developing a React component

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.
  • 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.)

Testing

Refer to the following issues:

Supporting projects

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.

jolokia.js

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.

hawtio-backend-middleware

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.

Communication and planning

Let's use GitHub Issues for communications including questions, discussing features, and bug reports.

https://github.com/hawtio/hawtio-next/issues

Developer's references