Expose renderless ui-components?

[jlsjonas]

This is a feature request.

Prerequisites

• [x] Are you running the latest version?
• [x] Are you reporting to the correct repository? (enso is made of many specialized packages: https://github.com/laravel-enso)
• [x] Did you check the documentation?
• [x] Did you perform a cursory search?

Description

Expose renderless UI components for overriding in own (VCS-able) code.

This would limit patches to rewriting the import in templates (or the templates themselves) instead of heaving potentially 100's of lines to be patched using patch-package for generic files

renderless snippet:

import Auth from '../src/core/layouts/Auth';
import Default from '../src/core/layouts/Default';
import Home from '../src/core/layouts/Home';

import App from '../src/core/App.vue';
import AppFooter from '../src/core/components/AppFooter';
import Bookmarks from '../src/core/components/Bookmarks';
import Breadcrumbs from '../src/core/components/Breadcrumbs';
import DocumentTitle from '../src/core/components/DocumentTitle';
import Loader from '../src/core/components/Loader';
import PageHeader from '../src/core/components/PageHeader';

import Navbar from '../src/core/components/navbar/Navbar';

import Menus from '../src/core/components/menu/Menus'
import MenuItem from '../src/core/components/menu/MenuItem'
import Sidebar from '../src/core/components/menu/Sidebar'

export {
    Auth, Default, Home,
    App, AppFooter, Bookmarks, Breadcrumbs, DocumentTitle, Loader, PageHeader,
    Navbar,
    Menus, MenuItem, Sidebar
};

I'd recommend splitting the file up in sections for a cleaner structure (i.e. renderless/components, ...)

[aocneanu]

Of course, that was on of the reasons for rewriting the ui as renderless.

If you have the time do a PR, add a renderless folder near bulma and export everything from core.

If not I will take care of it in the near future.

[jlsjonas]

Mimicking the folder structure or not? I overrode the module using above snippet under renderless but it gets messy quite quickly

[aocneanu]

The thing is that without mimicking the folder structure in time we could have a problem of name conflicts. But we can make a breaking change if this is the case at that point.

So better have everything at one level.

[jlsjonas]

Why not avoid future naming conflicts & provide a clearer structure from the get-go?

I'd recommend to at least separate components & layout; waiting on your 👍 to mold it into a PR.

[aocneanu]

ok then, use the existing folder structure

[aocneanu]

Any updates on this?

[jlsjonas]

Lost track of this one, will look for it this week.

(can't seem to assign myself btw)

[aocneanu]

merged