New State logic - customization flexibility

[robbykrlos]

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

Hi,

Regarding the new state logic, that dynamically loads states from your vendor modules:

We had some small changes inside the older AppState.php, which now is spread in all State.php classes.

Can we have more flexibility on class bindings? (replacing new $provider with App::make($provider))

vendor/laravel-enso/core/src/Services/State/Builder.php

private function state(Source $source): Collection
{
    return $source->providers()
        ->map(fn ($provider) => App::make($provider))
        ->map(fn ($provider) => [
            'mutation' => $provider->mutation(),
            'state' => $provider->state(),
        ]);
} 

Or is there another way of doing this? (I saw that there is a configuration enso.state,vendor that may offer some flexibility, but does not make things easier).

I can PR the App::make($provider) myself it you're ok with it.

[aocneanu]

Sure, make a PR.

Also, if the changes you're talking about could benefit Enso, we could adopt those as well.

[robbykrlos]

Hi @aocneanu,

PR done. PR: New State logic - customization flexibility #393 #188

As for the changes mentioned, the small changes in ex-appState are related to a bigger change in the permission logic, that adds a new layer that is grouping multiple roles. You have at the moment Users-> Roles-> Permissions. We made a User-> Groups-> Roles-> Permissions, which I believe is too much for a change to be adopted and not sure it's really a benefit for Enso. It's still giving us some headaches when applying :) #185

[aocneanu]

PR was merged a while ago.