Updating the Frontend and decouple codebase

[ReeceM]

Instead of opening an issue I thought this would be a better place to map out ideas.

The package has a lot of installs and likely a lot of users. There is also a pattern of other projects extending the project, but with a lack of API be it HTTP or Code level, they extract all the code and duplicate it. This sucks for them as they don't get any upstream benefits from what we add in this repo.

So the thought is potentially the following.

Frontend

We can set out for a dedicated frontend part of the application. With a separate frontend that can be split to a separate repo, or artisan publish --tag="maileclipse-frontend" sort of thing from the same package, this might be nicer.

Potentially we can use Inertia if we want to have a pure JS part, that a user 'could' override as the response is just a json file. They can reimplement a mobile interface should they wish.

The other option is to make the one used by the package based just on view as it is, this might be better for people who make a new PR, it's easier for them. This is also easier to test, there isn't the need for frontend tests.

To make use of a new frontend, there is a need for an improved, pragmatic way of getting and modifying mailable classes and such. So the backend would need to be adjusted.

Backend (API)

It would be great if the package could extract all the functionality of the main class into separate ones, then have interfaces and such for ones a person can override. For instance: One to handle storing the modified mailable templates, there can be a file/database or s3 one if wanted sort of thing.

Then the fact that there is a set of classes that are known and easy to access then a person could write their own frontend, or couple the package into their own application.

Tests

Currently the package relies on the usage of manual tests, this is useful, but also tedious and open to things being missed. It has worked alright. But if there are persons who haven't a good understanding of the codebase then they might not know what to look for when things aren't working. Or won't know if it's broken till we test/ tag the release.

Splitting the classes or making specific classes and actions we can then test find-grained functionality of the package, as some of the underlying stuff is supplied by Laravel e.g. Artisan tests.

Potential to add other editors.

As seen in early days of the package, there were some good suggestions to make use of some other mail editing tools. This could potentially in the future be done as a plugin sort of thing.

These are all suggestions and are fully open to changing but it is an observation and would likely improve the uptake of a person making a PR when they see something, it would also embrace the Laravel community way of doing things and in general improve the package for future maintainability :)