README
@acanto/core-barba
Due to its natura the integration of barbajs is done at multiple levels and is taken care also outside of this core package.
Routes definition
The file src/vendor/routesBarba.js is autogenerated by @acanto/laravel-scripts, the idea is to keep having a per route isolation both in terms of JS entrypoints and CSS inlined per route. The latter is simply managed through inlining the new route's CSS inside the asynchronously fetched new route's html and disabling the old one beforEnter. Each of these CSS are <style> tag with a conventional id like__route-style-${id} and generically matched by the data attr data-route-style. Per route JS handling is a bit more complicated, and the reason for the existence of this autogenerated file. Webpack async imports cannot have a variable in their path, hence we precompile routesBarba.js with the routes information returned by the CMS during the build step in the CI (and on npm run start too). We build a barba view for each of our routes, attaching the barba hooks to standard lifecycle methods of the routes' entrypoints components: beforeEnter => route() (basic component instantiation), afterEnter => route.mount(), afterLeave => route.destroy(). For some of this topics see this github issue where it suggested to just create a single js/css file, which might also work if we automatically scope the css on the entire page. But at the moment, with the current approach we are free to keep having global styles applied per route without having to worry of style collisions, for instance we can have each route specifying a body background without having to scope the css selector and that's something useful and comfortable to use. Also JS might become very heavy if we just pack everything in a single file...
Components and layout
The only file that would need changes is the layouts/{main}/index.blade.php which should be something like what you find here in the default template
JavaScript lifecycles
Routes should use the HOC @acanto/core-barba/route ...TODO: docs