Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leaf MVC v4.0 #36

Draft
wants to merge 243 commits into
base: master
Choose a base branch
from
Draft

Leaf MVC v4.0 #36

wants to merge 243 commits into from

Conversation

mychidarko
Copy link
Member

What kind of change does this PR introduce? (pls check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe below

Description

leafmvc-4-post-wide

This was a bit unexpected even for me, I started of working on the changes suggested in the last blog post which talked about how Leaf MVC had grown in bloat, but the goal was to quickly clean up the bloat and push out a v3.8 which had no breaking changes. While this was done, other fixes like re-organizing the view layer which was carried over from v1 of Leaf MVC added a number of breaking changes. While there were ways to keep the changes subtle, they would have unnecessary costs for performance.

So yes v4 of Leaf MVC. This major version is going to focus on the usability part of Leaf MVC. Building on what what written in the post, we are going to move a lot of things away from the Laravel/Ruby on Rails way of doing things, and it will be a completely different, but natural way of thinking about your applications.

While it introduces a different way of thinking about your applications, your code will look a lot like what you are already used to, so there's no need to panic about relearning everything you already know. Well, let's look at the major changes you can expect in the upcoming version.

Leaner directory structure

As mentioned, we are going to cut down on the number of files and folders which are shipped with Leaf MVC by default. This will make it easier to keep track of everything in your application without toggling folders and going through tons of files. This will also make it easier for beginners to catch on to what's actually going on since they won't have any useless directories distracting them.

So we'll move from a directory structure that looks like this:

├───app
│   ├── console
│   ├── controllers
│   ├── database
│   │   ├── factories
│   │   ├── migrations
│   │   ├── schema
│   │   └── seeds
│   ├── helpers
│   ├── models
│   ├── routes
│   └── views
│       └── errors
├───config
├───public
│   └───assets
│       ├── css
│       └── img
├───storage
│   ├───app
│   │   └───public
│   ├───framework
│   │   └───views
│   └───logs
└───vendor

to one which looks like this:

├───app
│   ├── controllers
│   ├── database
│   ├── models
│   ├── routes
│   └── views
│       └── errors
├───public
│   └───assets
│       ├── css
│       └── img
└───vendor

Smarter loading of files/modules

v3 of Leaf MVC had some installation commands which were different from the ones used in Leaf, and that was a source of confusion for some developers. v4 is solving this by allowing Leaf MVC auto-configure modules so you don't have to use any funny commands to do all of that anymore.

In addition to modules, files like console commands and custom libraries are automatically loaded into your application and no longer require you to add or remove any lines from any file

This also applies to view engines

Revamped view engine layer

Leaf MVC has always allowed you to add any view engine of your choice, but Leaf MVC v4 does this without you having to go through the trouble of attaching the engine to Leaf first. This means you only need to set up the config/view.php with your custom engine and Leaf MVC will handle everything else for you, including attaching the engine to Leaf.

Beyond that, the entire view layer has been re-written to include things like view engine and view config caching which have lead to an almost 100% performance gain

Auto configuration

Leaf MVC v3 relied on the config files present in the config folder and would throw errors if an expected file was not found. v4 moves away from this by relying on internal configuration before looking for any user-added config files. While this is slightly less performant, it offers a better experience and allows v4 to run without any visible config files further cutting down the clutter in your applications.

A lot more of the config is adjustable using your .env file which means it's easier to separate your configuration between different environments.

Lean starter

Leaf MVC v3 followed Laravel's batteries-included philosophy, but we believe it's much easier to incrementally add to your applications than to deal with features you don't need taking up space in your application. To be fair, every feature you need is one leaf install away.

Once installed, Leaf will automatically set up any module and will allow you to publish config files for that module if needed.

DB Schema files

Going back to how we are moving away from the Ruby on Rails/Laravel way of doing things, we are exploring a better way to set up your databases without having multiple files for each table which can quickly get out of hand. We promised this will be our christmas gift to our community, so we are going to keep it sealed until the first RC of Leaf MVC v4

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

Related Issue

mychidarko and others added 9 commits November 12, 2024 20:20
This commit fixes an inconsistency between:
- User model (using 'fullname')
- Migration template (using 'name')
- Schema JSON example (using 'name')

This ensures consistent field naming across the framework.
…ency

fix: Change User model fillable field from 'fullname' to 'name'
@mychidarko mychidarko marked this pull request as draft December 8, 2024 21:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants