Something like Arr::toCssClasses but for dot

[mjamilasfihani]

hi! is there any helpers that can transform from ['foo' => true, 'bar'] into foo.bar ?

[mjamilasfihani]

because I need to work at multiple same route path with a different route name, so I just make macro like this;

public static function toRouteNames($array)
{
    $routeList = static::wrap($array);

    $names = [];

    foreach ($routeList as $name => $constraint) {
        if (is_numeric($name)) {
            $names[] = $constraint;
        } elseif ($constraint) {
            $names[] = $name;
        }
    }

    return implode('.', $names);
}

I just figure it out from Arr::toCssStyles, and hopefully it can help folks out there.

cheers.

edit: it was wrong code, sorry.

[benjdiasaad]

Nice idea—borrowing the pattern from Arr::toCssStyles fits well here.

If the goal is to build dot-notated route names from a mixed array, you could simplify and make it a bit more expressive using collections:

public static function toRouteNames($array)
{
    return collect(\Illuminate\Support\Arr::wrap($array))
        ->map(fn ($value, $key) => is_numeric($key) ? $value : ($value ? $key : null))
        ->filter()
        ->implode('.');
}

This keeps the intent clear and handles both keyed (['foo' => true]) and non-keyed (['bar']) values consistently.

It might also be worth defining how you want to handle non-boolean truthy values or nested arrays, depending on how generic you want this helper to be.

Overall, neat utility, this pattern is definitely useful for dynamic route naming.

[mjamilasfihani]

hi @benjdiasaad thanks for the response!

~ glad to know you notice it 😄

I'll give a shoot later. at moment it's only a basic that I needed, something like this:

URL::macro('barRoute', function (string $name, mixed $parameters = [], bool $absolute = true) {
    $names = Arr::toRouteNames([
        'foos' => $this->getRequest()->route()->hasParameter('foo'),
        'bars',
        $name,
    ]);

    return $this->route($names, $parameters, $absolute)
});

so when I use app('url')->barRoute('settings.show') for generate the url, it will resolve both:

• dashboard.saas.com.test/{foo}/{bar}/settings -> foos.bars.settings.show if {foo} is existed
• saas.com.test/{bar}/settings -> bars.settings.show if {foo} doesn't exist.

note: for folks out there, if you had an concern. I have set URL::defaults() with conditionally checking parameters before.

---

This keeps the intent clear and handles both keyed (['foo' => true]) and non-keyed (['bar']) values consistently.

yes! thank you very much for the point.

~ cheers

[benjdiasaad]

Nice, this makes the use case much clearer,

The macro approach is clean, and I like how you're conditionally building the route name based on the presence of {foo}—it keeps things flexible without duplicating route definitions.

Using URL::defaults() alongside this is also a solid call 👍 it avoids unexpected missing parameters at runtime.

One small thought: depending on how this evolves, you might want to guard a bit against cases where the current route is null (e.g. running in console or certain edge contexts), just to keep it fully safe.

Other than that, this is a neat pattern for multi-tenant / scoped routing, simple and effective.

Thanks for sharing this 🙌

[shaedrich]

I wonder why you want to pass this in with said shape rather than just a mere list. In what real world scenario would you want to have ['a' => true, 'b' => false, 'c'] to result in a.c? And why do you want a trailing dot?

[mjamilasfihani]

hi @shaedrich thank you for asking!

I am sorry for the confusing,, let's start with an URLs list:

• saas.com.test/{bar}/dashboard
• dashboard.saas.com.test/{foo}/{bar}/dashboard

as you can see, the 1st list contain a bar model, which is the main product of my, yours or someone else. and by default it owned only by a regular user or customer. and the 2nd, main product or bar can also be owned by foo, which is another type of user (you can also called it by brand/company/org).

by far we already know, between a regular user/customer and brand/company/org had it own path, isn't? and then, we hit a situation that some modules of bar must be loaded in both paths (same controller, validation, models, etc, etc).

why? because you don't want to write "exactly" same modules for a different scope. and if you realize we are inside a domain's pattern (one of the commons way to leverage Laravel usage).

---

in my scenario; bar is as invitation and foo is as organization. then inside an invitation, one of the examples: I had a Bride's model that hold brides information and it's controller, validation, routing, etc, etc. because it can be used in both scopes, then I only need to load the routes inside web.php and dashboard.php. and I already have a route names; invitations. and organizations.invitations. before, it will be invitations.brides.{show|edit|update} and organizations.invitations.brides.{show|edit|update}.

so when you in the bride's controller you will be asked; where do I need to go after updating the resource? it can be invitations.brides.show's itself or organizations.invitations.brides.show. of course we can use if-else for the redirecting, but? how about the blade's side?

then we decide to create an app('url')->routeInvitation(...) method registered via URL's macro that did the same thing as app('url')->route(...).and, as you can see {foo} or {organization} will only exists into url's segment if the current user is brand/company/org, so the route lists inside the macro's closure will be ['organizations' => $this->getRequest()->route()->hasParameter('organization'), 'invitations', 'brides.show'].

I think it is.

-cheers

[mjamilasfihani]

ohhh, and the application that ended up in the these situation are small by chance I think.. but what's your opinion?