WIP/Draft Responsive design and webpack

[artfulrobot]

I'm opening this PR as a draft to invite comments, as it's one you're going to either love or hate :-) If you hate the direction then it would be good for me to know that sooner rather than later.

Pull request checklist

Please check if your PR fulfills the following requirements:

• [ ] Tested the changes
• Build (/path/to/php cli.php cmd=build) was run locally and any changes were pushed This PR retires this (though requires a different build step)

Pull request type

Please check the type of change your PR introduces:

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no api changes)
• [X] Other (please describe):

This PR does two things:

1. It addresses #693 by implementing Laravel Mix, a user-friendly way to drive Webpack. Please see README-mix.md for my documentation of these changes.

2. It includes the beginnings of my work to make OWA responsive and workable on a wider range of screen sizes, from mobile up.

What is the current behavior?

• CSS, JS compiled with PHP build script via cli.php
• non-responsive design

Issue Numbers: #693 #692

What is the new behavior?

• CSS, JS compiled with Laravel Mix (webpack)
• responsive design (begun)

Wide view:

Mobile view:

Mobile view with menu open

Nb. I still have work to do on responsiveness; this is a draft PR.

Does this introduce a breaking change?

• [X] Yes
• [ ] No

Some output files have moved - see the README-mix.md document.

Docs need to be updated?

• [X] Yes
• [ ] No

Content from README-mx.md should be merged as instructions for developers. User-use should not have changed.

Other information

The tracker script has dropped in filesize from ~75k to ~50k.

[padams]

Whoa. Very cool to see this. It's going to take me a bit ot get through the changes but the first thing I'm wondering about is how to namespace and otherwise keep seperate the CSS and JS from modules which all can be turned on and off via the admin GUI.

It feels like each module should have it's own src directory structure and then packed files would be stored to a single dist directory that lives at the top level. For example something like this:

/modules/base/src
/modules/base/src/js
/modules/base/src/scss
/modules/somemodule/src
/modules/somemodule/src/js
/modules/somemodule/src/scss

/dist/ --> all compiled files wind up here.
/dist/base.min.js
/dist/base.css
/dist/somemodule.min.js
/dist/somemodule.css

This would allow each module to be built/compiled separately as they are developed and then have all packed production js and css served from a single top level directory.

Not sure if that implies that each modules would need its own manifest.json file or not but I'd like to maintain the ability for module developers to work independently without having to modify any top level or base module config files in anyway.

[padams]

Actually in hindsight a single top level dist directory would force users to run the build step whenever they activate a module and we don't want to include node in an OWA release distro.

So it's better to have each module have its own src and dist dirs I think.

This allows for module developers to package and distribute their distros.

[artfulrobot]

@padams Thanks for your feedback (which I'm taking as encouragement!).

The filepaths gave me a headache - and were very fiddly to separate out the various bits, update the relevant filepaths etc. I'm also not 100% sure I've managed to net all the owa-specific stuff separate to the 3rd party libs. But anyway, this PR is WIP/Draft. I'm using OWA with this and keeping an eye out for anything broken at the same time as working on making it responsive.

There's some weird stuff too, like in owa_view where CSS is apparently added by a setJs call?

I like the idea of a clean dist/ dir but as you say, this limits what can be turn off and on -able by admins. It's always a balance. There's no reason why we couldn't - if it was v important - include a build step that just concats files that are enabled; so we'd still be benefiting from the more modern compilation, sass, minify, babel etc.

Also, I'm new to OSA and completely new to the codebase, so I expect I will make mistakes / not know stuff!

Thanks for your time (and the great project).

[padams]

No worries! We will wrangle this together. How do you feel about separate src and dist dirs per module?

[artfulrobot]

How do you feel about separate src and dist dirs per module?

I like it.

But it will leave the problem of the main tracker.js file; unrealistic/dangerous to move that. Could deploy to both places for an interim period with a deprecation?

Also, what do you want to do about library assets (there are images for ex) - leave them in src and update URLs to point direct to the src dir?

Nb. it's possible (but I'm not sure I have the appetite for it!) to specify the versions of most library code in the package.json file, which means, in theory, that it's easier to update, although we're way behind on versions e.g. jQuery, so I expect that would be a lot of work. I'm focussed on getting the responsive design working at the mo, as it was a blocker to me using the project - I'd like to persuade my clients to use this instead of Google Analytics, for the sake of better privacy/respect for humans, and a big part of that is whether it works right on their devices.

[padams]

Yeah the tracker location needs to be maintained. I wonder if we could use .htaccess to handle the redirect from the old location to the new. Would have to sort out a strategy for nginix too.

Re images... I think each module should have an assets dir perhaps with an `images/' subdir.

Re: library versioning. Yes lets punt on that for the first go around and then we can incrementally move them to the package manager over time. That's what we are doing with Composer.

[artfulrobot]

tracker code: how about we build it to dist/ with the others, and update the outputted tracker snippet to reference that there, but also copy that to the original location. It would be feasible then to put a check in for that file: if it exists (which it would be default) we could flag it to admins as "you may still be using the old tracker snippet; please update your sites to use the new one code, then delete the file at /path/to/old/location/tracker-min.js"). Bit messy. An alternative would be to build two versions such that we could actually track which of the two versions was in use when calls are made to track stats. Then we could issue the warning if the old location has been used within the last few days, for example, and which sites are using it.

I think for now I'll just copy it to both places.

FYI: Have got swamped with other work at the mo, so slowing down on this for now, but still keen.

[padams]

All the npm and webpack infrastructure is in place now. Did not go with Laravel Mix as we needed to wrangle the underlying webpack stuff directly. Do you want to close this and start a new PR using what's in place?

[artfulrobot]

Hi @padams I'm afraid I'm not longer using OSA (gone to Plausible) and won't realistically get around to making a new PR.