HOF Component Design

[JoeChapman]

HOF Component Design requirements and considerations:

What do we hope to solve with components?

• Simple embedding of re-usable UI elements into apps.
• Remove need for implicit cross-dependencies across modules - e.g. relying on templates, which are only present as a side-effect of another module being present.

What would the interface for a component look like?

TBC - but would almost necessarily be exposed in the form of middleware.

How could a component integrate with HOF?

As express middleware. A hof implementation (or hof itself as appropriate) should be able to app.use(component) and have that work fairly seamlessly.

What elements of an app could a component replace?

• The current dependency on hof-template-partials to have been mounted in an app for many elements of functionality to work - functionality should ship with it's own templates.
• The hof-template-mixins module, which has become a dumping ground for largely unconnected pieces of functionality.

Where do we start?

• Defining a proposed component API that satisifies our basic needs
• Using hof-template-mixins as a primary target, perform an internal refactor of that module to "component-ise" the input components that are present within that module. Once the elements are component-ised then they can be split into standalone modules if we think that is appropriate.
• Identify common shared elements of components, and look to abstract where necessary.

[sulthan-ahmed]

Good questions, could I also ask, what components do we need? Address-lookup?

[JoeChapman]

The HOF Component concept is driven by a desire to remove cross module dependencies where the use of one module might require the need for another. You could refer to it as peer dependencies.

[JoeChapman]

One approach we might take to lessen the burden on the developer when implementing a HOF app is to ship co-dependent resources together. Such as in the case that a field - called 'foo' for example purposes - requires a specific translation, controller or style. That might be as a module, e.g. hof-component-foo. Or in the case where foo is necessary to HOF core, it is baked into hof

[lennym]

Address lookup is probably a bit big for what we're describing here. It might incorporate components, but probably wouldn't be a component.

Initial targets for components would be:

• most of the things in hof-template-mixins- the input fields, or markdown blocks
• the existing date component, but refactored into a form which was compatible/consistent with the above

Broadly speaking, they would be modules that can be embedded into a page, but that contain all their own functionality/templates/translations in a single module, without needing other implicit cross-dependencies.

[JoeChapman]

Componentising collections of elements such as Address lookup would be ace (IMO), but as Lenny has just pointed out, "probably a bit big for what we're describing here".

[lennym]

I heard React is cool.

[sulthan-ahmed]

me too, heard it's componentised.

Are we thinking of making HOF work in/with React? What are the reasons?