shopware / SwagShopwarePwa

This extension adds additional endpoints to your Shopware 6 platform to let it integrate with Shopware PWA.
40 stars 17 forks source link

Make MATCH_MAP in pathResolver.php extendable #93

Open meeshoogendoorn opened 2 years ago

meeshoogendoorn commented 2 years ago

When we create the option to extend the MATCH_MAP we are able to create custom views for the pwa like frontend.blog.page for example.

Right now hen we want to create a new resourceType for a new kind of page we have to do the following in the SwagShopwarePwa plugin.

luismarquesfreire commented 2 years ago

Just stumbled upon this as well. We really need this for having custom entities on PWA.

meeshoogendoorn commented 2 years ago

@elkmod Is this possible to build in the next update. if we could extend it from our own custom plugins. That way we could create blog or storeLocator plugins that would be compatible with SwagShopwarePWA plugin. Right now we have to change this with every update.

I would like to contribute to this issue but don't have any clue how to overcome this problem and what would be the best way😌

elkmod commented 2 years ago

Hi @meeshoogendoorn - sorry for the late response here. We are hesitant about that change, because the MATCH_MAP constant is already a workaround in itself.

Do you remember having to select a "Storefront" sales channel type when setting up shopware-pwa? This was, because we use some SEO-URL "magic" that is only defined in the shopware/storefront package, so we can use pretty URLs following an arbitrary template (such as shop.com/my-category/p-142523/this-is-a-nice-shoe).

That "magic" is defined in this namespace. You can see that there is one file for each entry in PathResolver::MATCH_MAP. When there is no "SEO URL" present for the given entity, we can fall back on the "implicit" routing. That routing is defined in the respective controllers (which are also part of the shopware/storefront package):

Long story short - we would have to replicate all the routes mentioned above within SwagShopwarePwa to get rid of the dependency on shopware/storefront. But in the long term, we would like to get rid of that workaround and, hence we don't want to introduce a way to extend it in the first place, which I hope makes more sense now.

The "clean" solution to the problem you are proposing would be to provide custom route classes implementing Shopware\Core\Content\Seo\SeoUrlRoute\SeoUrlRouteInterface, so that they will be properly resolved in the first step of the path resolving process.

meeshoogendoorn commented 2 years ago

I understand, I will look into the clean solution. What i thought was because of custom entities is only something developers would use we maybe could create a config file in config/packages named shopware_pwa.yml where we could define an array with key and regex like the following:

match_map:
    - { index: frontend.blog.page, regex: ?^regex_string/$ }
    - { index: frontend.news.page, regex:  ?^regex_string/$ }

We would create the following configuration treebuilder class:

<?php

declare(strict_types=1);

namespace SwagShopwarePwa\Configuration;

use Symfony\Component\Config\Definition\Builder\ArrayNodeDefinition;
use Symfony\Component\Config\Definition\Builder\TreeBuilder;
use Symfony\Component\Config\Definition\ConfigurationInterface;

class Configuration implements ConfigurationInterface
{
    public function getConfigTreeBuilder(): TreeBuilder
    {
        $treeBuilder = new TreeBuilder('shopware_pwa');

        $rootNode = $treeBuilder->getRootNode();
        $rootNode
            ->children()
            ->arrayNode('match_map')
            ->arrayPrototype()
            ->children()
            ->scalarNode('index')->end()
            ->scalarNode('regex')->end()
            ->end()
            ->end()
            ->end()
            ->end();

        return $treeBuilder;
    }
}

and process it on installation of the swagShopwarePwa plugin 👨‍💻

and we could use that array as a workaround. That way we could extend the workaround without to much changes. But i will look into the cleaner solution to see if i can get it working 😄 Thanks for the response.

meeshoogendoorn commented 2 years ago

Well while looking into LandingPageSeoUrlRoute found a very small typo

  throw new \InvalidArgumentException('Expected ProductEntity');

Should be

  throw new \InvalidArgumentException('Expected LandingPageEntity');

on following line: referenced line