aniftyco / kubit Goto Github PK

Right now we just depend on Youch and let it default, but we want to move it directly into the framework so that way we can style the page to match our branding.

Sometimes it can become pretty unweildly having a bunch of Route.group(() => { ... }) in your routes, so we could make this a bit better by allowing you to pass a path string into the group method which will then tell Kubit to import that file and execute it in the context of the route group.

This could allow you to split things up

Route.group('./dashboard');
Route.group('./admin').domain('admin.example.com');

We can migrate a lot of the original Adonis tests over, but will have to do it in component steps because some of them will be heavily modified due to our changes, so wholesale bringing them over may not be as easy.

Be nice to have a package that extends Adonis/Kubit to add features for working with htmx in an application as that'll be a primary tool in all our apps.

Based loosely on https://github.com/mauricius/laravel-htmx.

We can extend the Request class to add some of the helpers and look into seeing if we can extend Edge to have support for fragments too.

Bouncer functionality should just be apart of the auth component and not a 3rd party package.

Right now the view component just supports Edge templates, but we want to abstract it into a manager pattern to support other rendering methods.

This is because Kubit being a traditional MVC backend framework written in JavaScript/TypeScript we're in a unique position to support other view layer renderers such as a React or Vue or even Svelte renderer allowing us to bridge the backend and frontend in truly cohesive ways that neither the modern JavaScript based frontend nor traditional backend frameworks ever fathomed.

First we'll add support for using Vue Single File Components (SFC) as a template renderer to return the string contents directly to the browser, but ultimately the end goal is to support full SSR and client side rehydration of modern frameworks like Nuxt, Remix, and Astro, utilizing the Astro Island architecture for client rehydration by using the defer keyword on a <script setup> tag.

So take the following example code

resources/views/components/Greeter.vue:

<script setup defer lang="ts">
import { ref, onMounted } from 'vue'

const { name = 'World' } = defineProps<{ name?: string }>();

onMounted(() => {
  setTimeout(() => ref.value.innerText = `I'm Batman!`, 1000)
});
</script>

<template>
<h1 ref="greeter">Hello, {{ name }}</h1>
</template>

<style scoped>
.h1 { color: red }
</style>

Then you had this page view

resources/views/pages/home.vue:

<script setup lang="ts">
import Greeter from '../components/Greeter';

const { name } = defineProps<{ name: string }>();
</script>

<template>
  <Greeter :name="name" />
</template>

And you called it in your controller or route handler like so

return view.render('pages/home', { name: 'Josh' });

What would happen here is we would detect that the view home maps to resources/views/pages/home.vue and specifically see the file extension is .vue and it would then render this view using the Vue Renderer. So that would render the home.vue page, which would see that it imports Greeter component. Render the static html string server side, and generate a manifest to load what JavaScript in the browser because the <script startup defer> in the Greeter would tell the Renderer that it has client interactivity and thus needs to inject the necessary JavaScript for that component to hydrate and render client side, which after 1 second would change the contents from "Hello, Josh" to "I'm Batman!".

While building Makerlog I have ran into a need for the official Adonis Attachment-Lite package and it looks great, but it's missing some features that I'd like but doesn't seem to be possible without an overhaul and I'm not entirely sure if they're game for that.

While looking into alternatives I did find Responsive Attachment which is a fork of Attachment Lite that adds generating responsive image sizes, which is cool, but also limits the type of attachments that can be used to just images.

The Attachment Advanced package seems to support generating variants and previews for all file types, which is better, but is missing a key feature I still need...

Added features

Multiple Attachments

Not only would it be nice to generate responsive variants and previews of the attachments, at least in Makerlog's case we'll need to support not just a single attachment per record, but potentially multiple attachments of varying types.

With the whole fiasco about Redis, Inc changing from BSD license, this has prompted me to rethink a bit about this module and instead of being redis we should refactor it to kv and make it use the driver pattern and support other key/value stores also.

Kubit should come with a way to auto-generate sitemaps and robots.txt

Utilize satori to create a package to generate open graph images on the fly, sorta like @vercel/og but not on their infrastructure.

Right now I have the bootConfig (formerly the rcfile) hardcoded into the application component, it allows for shallow extending but that's fragile and could break things if you try to extend the wrong thing. So we need to refactor this and allow deep extending the config.

Logger middleware for every incoming request. i.e

import type { HttpContextContract } from "@ioc:Adonis/Core/HttpContext";

import { default as Log } from "@ioc:Adonis/Core/Logger";

export default class Logger {
  public async handle(ctx: HttpContextContract, next: () => Promise<void>) {
    Log.info(`[ Req ] ${ctx.request.url()}`);
    await next();
  }
}

The core team is working on a SSE package for v6, but we're staying on v5 for a while until the ecosystem catches up to the changes. So we'll need a better implementation of SSE events and this is what I was thinking.

The package registers a service provider that sets up an endpoint /events to connect to with a EventSource object on the client side. It also publishes a config/sse.ts file that from the top of my head just gives a you the ability to define what events can be broadcasted to the endpoint from the built in Event system.

So say you have this in your config:

export default sseConfig({
  events: ['chat:*'],
});

This will then start listening and broadcasting all chat: prefixed events to the endpoint. So in your application you can just do:

import Event from '@ioc:Adonis/Core/Event'

import type { HttpContextContract } from '@ioc:Adonis/Core/HttpContext';

export default class ChatController {
  public async create({ auth, request, response }: HttpContextContract) {
    const { message } = request.input('message');

    Event.emit('chat:message', { user: auth.user.name, message });

    return response.status(204); // successful but no content.
  }
}

This will then broadcast that event details to the client side.

A lot of apps utilize geo data for various things, such as authentication to tell the user where that session originated from. It would be nice to utilize internally something such as maxmind database to expose a request.geo object in the request context with the parsed out geo data for that user, such as city, region, country.

This package is a core component and must utilize the redis component.

So that way we can define optional hooks for various states in the lifecycle of a job.

Just like in #62, it would also be nice to parse the user agent and return an object of details about the device such as if it's mobile, desktop or tablet, operating system, browser, etc and store it on request.device object in request context.

If you've landed on this repository you may be asking yourself what exactly is Kubit and why does it exist? Well I'm here to tell you.

Kubit is/will be a highly opinionated version of Adonis MVC Framework. Think of it as like the Laravel of Symfony framework. We aren't forking all of Adonis nor are we planning to rewrite it from the ground up. We're simply going to export a few packages of our own that wrap Adonis' core packages to add extra functionality that we find ourselves wanting in a framework but maybe the overall Adonis community may not. Instead of having a bunch of random boilerplates that become out of sync with the framework or become hard to keep updated with upstream, we've opted for this method because of how highly customizable Adonis is.

Some things we can see as being developer experience improvements such as riding ourselves of the ace/ace.js file in the root of the project. Most modern frameworks don't need something like this and Adonis doesn't either, but it's not hurting anything in the main framework by existing. So in Kubit we'll be pulling that back into the framework core and exposing a node binary for doing those actions.

Other things include having stuff that is necessary for most of the apps we build or will target building bundled into the framework like mailing, databases, queues, scheduling, etc.

We also plan to try and contribute a lot of our stuff back into Adonis itself if the community wants it, including building high quality addons that the wider Adonis community can use independently if they so desire.

For example we'll be forking @adonisjs/mail to add in support for rendering email templates using such existing tools as Maizzle so that you can write standard html templates and get emails that work in all mail clients out of the box.

If this is something that interests you, feel free to star and follow the repository. If not no sweat you're free to use whatever you want.

We need to bring BullMQ up to latest version, and implement more advanced queue/job features like methods in the Job class for chaining on dispatch for changing what connection that job should dispatch to.

ExampleJob.dispatch({ ... }).on('other-connection');

Also things for controlling the job when dispatching like setting default config on the job class itself, and overriding those with a second param on the Job#dispatch(payload, options) method.

Right now it just copies over the contents of templates/web/ into your directory, then runs cp .env.example .env for you, but we can take this a step further and make it smarter by generating the .env based off .env.example as a template. Like it will see APP_KEY in there and generate it for you already.

Then we can also have it update package.json with the latest version of kubit so that way every call will always ensure the latest is installed not the one that is in the template.

Japa for unit/functional tests is fine, but we also want to integrate Playwright for native E2E testing.

Right now you can do Route.on('foo').render('bar', data); and it will work, but it would be nice to shorten

Route.get('foo', ({ view }) => {
  const data = await getData();

  return view.render('bar', data);
});

Into a BriskRoute method like this

Route.on('foo').render('bar', getData);

This package is a core component and must utilize the redis component.

In both the redis and database components we should allow you to pass off a single url string for a connection to support such abilities of the DATABASE_URL and REDIS_URL env var conventions without having to split it up and reconstruct the object from that.