[commits] [Wiki] created: Doc/Dev/Frontend

[Wiki Guest]

guest [31.16.249.142]  Sat, 18 Dec 2021 10:15:39 +0000

Created page: https://wiki.horde.org/Doc/Dev/Frontend

+ Frontend Development Proposal

Modern Single Page Application frontends may be awkward to maintain in  
the application repo itself. This proposal is about how to deal with  
it, without being too specific on the toolchain to use.

++ Patterns as of Horde 5

In the past, Horde Javascript would be stored uncompressed alongside  
the PHP source code and would be bundled and compressed (and cached)  
at runtime. Depending on the selected view type (Dynamic, Basic,  
Smartmobile), the framework would dish out some boilerplate HTML  
alongside with a backend-generated topbar, some runtime-generated  
"live data" javascript blobs like translation strings, user keys etc,  
and a bundled version of the relevant javascript and css. Some  
Javascript would be auto-included by choice of the view type without a  
good way to opt-out. This is all driven by some "page_output" class  
which is optimized for directly generating output to the browser or to  
output buffers rather than dealing with strings or streams.

Some of Horde's default boilerplate would be based on prototypejs and  
scriptaculous for the dynamic view or jquery-mobile and jquery for the  
basic view. While jquery is somewhat alive, query-mobile and  
prototypejs/scriptaculous must all be considered dead as of 2021.


++ Proposed pattern for Horde 6.

Roles and responsibilities should be redistributed as technology  
evolves. There have been some experiments with alternative frontend  
technologies like ReactJs.
As an application suite, Horde strives for some consistent look and  
feel between its different parts and views, leaving some limited  
choice of colors, icons and styling to the actual application. As a  
framework, horde should define communication between the backend and  
the consuming frontend and maybe some default implementation, but  
should not get into the way of developers doing something entirely  
different. This would enable reuse of the same API for alternative  
frontends or mobile apps.

* horde-components should have some developer support for frontend  
development. The raw frontend code should be a separate repo from the  
Horde app. The name of that repo should default to $app + underscore +  
"frontend" like "passwd_frontend" and be in the same path or  
organisation as the backend code. It may bundle or include any  
libraries it needs.
The default location to checkout that build is /frontend inside the  
backend app checkout and that path should be .gitignored. The frontend  
technology should include a "make-horde" executable that would build a  
production optimized version of the code and deliver it to  
/themes/default and to /js dirs. An optional make-horde-dev version  
with source maps and less optimization overhead may exist. The  
frontend technology may have a self-refreshing development version  
delivered by some server.

TODO: How to facilitate injecting a proper session and environment  
into that scenario?

* the frontend source code may be javascript, typescript, or any other  
language and would be transpiled and bundled into a build in the js/  
and themes/default/ folders. This build may still be bundled, cached  
or otherwise processed by horde.

++ TODO

* reusable UI parts which may be leveraged by portals or UIs of other apps
* themeing and translation definitions