In our setup, multiple sites are deployed with the same code base. So it would make sense to reuse a lot of the testing code for all sites. To achieve this we decided to reuse the same Docker container and provide the needed configuration variables via the entrypoint script.

We have a config Folder in the cypress Folder and are building the final configuration file together from all the pieces.

To do so we use the index.js file in the pluginsfolder:

(we also installed the merge-json npm package)

const fs = require('fs-extra');
const mergeJSON = require('merge-json');
const path = require('path');


async function getConfigurationByFile(division, environment, locale) {


    let defaultConfig = {
        "env": {"localePrefix": locale}
    };

    const filePaths = [
        path.resolve(`cypress/config/${division}`, 'defaults.json'),
        path.resolve(`cypress/config/${division}`, 'pages.json'),
        path.resolve(`cypress/config/${division}`, 'seo.json'),
        path.resolve(`cypress/config/${division}`, `env-${environment}.json`)
    ];

    for (let filePath of filePaths) {
        const config = await fs.readJson(filePath);
        if (config.env) {
            Object.keys(config.env).forEach((key) => {
                config.env[key] = JSON.stringify(config.env[key]);
            });
            defaultConfig = mergeJSON.merge(defaultConfig, config);
        }
    }

    return new Promise((resolve, reject) => {
        resolve(
            defaultConfig
        );
    })
}

module.exports = (on, config) => {
    const division = config.env.division;
    const environment = config.env.environment;
    const locale = config.env.locale;

    return getConfigurationByFile(division, environment, locale);
};

Cypress does only allow to store key / value pairs env of the config. Therefore we apply JSON.stringify() on them and later on in the spec file we parse them back to JSON objects JSON.parse(Cypress.env('<env_key>'))

Complex Configuration in Cypress.io was originally published in EcoLogic on Medium, where people are continuing the conversation by highlighting and responding to this story.

EcoLogicAG/datocms-plugin-multiselect

The Beginning

ng new datocms-plugin-<purpose>
npm install --save datocms-plugins-sdk

You won’t need a router for the plugin.

Add the DatoCMS CSS to index.html

<head>
   ...
   <link href="https://unpkg.com/datocms-plugins-sdk/dist/sdk.css" media="all" rel="stylesheet"/>
   ...
</head>

https://github.com/EcoLogicAG/datocms-plugin-multiselect/blob/master/src/index.html

Import the SDK in app.component.ts

import DatoCmsPlugin from 'datocms-plugins-sdk';

...

export class AppComponent implements OnInit {

   ...

   ngOnInit(): void {
      DatoCmsPlugin.init((plugin) => {
         
         ...

      });
   }
}

https://github.com/EcoLogicAG/datocms-plugin-multiselect/blob/master/src/app/app.component.ts

Do your stuff with the template and the component.

https://www.datocms.com/docs/plugins/sdk-reference/

For development and testing you can serve the app on http://localhost:4200 as usual. Then create a new private plugin over at DatoCMS and use http://localhost:4200 as the “Entry point URL”. (You have to allow unsafe content in the browser for testing)

Publish

https://www.datocms.com/docs/plugins/publishing/

What Went Wrong

The plugins are served on unpkg.com from a subdirectory, eg. https://unpkg.com/@ecologic/datocms-plugin-multiselect@0.0.7/dist/index.html

For this to work with Angular we need to adapt the <base href=”/”> path in index.html. The easiest way to do this is using the package.json file:

{

...
   "version": "0.0.7",
   ...
   "scripts": {
      "build": "ng build --prod --configuration production --base-href https://unpkg.com/@ecologic/datocms-plugin-multiselect@$npm_package_version/dist/ --output-path dist"
   }
}

EcoLogicAG/datocms-plugin-multiselect

Then build and publish your plugin an you should be fine.

Create a DatoCMS Plugin using Angular was originally published in EcoLogic on Medium, where people are continuing the conversation by highlighting and responding to this story.

do is now named tap

The reason for this change is, that do is a reserved keyword in javascript.

.pipe(…) is used to chain operators

Before

Now

imports are simpler

There are now only two locations where we need to import from:

// operators
import { map, tap, filter } from 'rxjs/operators';

// helpers, schedulers, types, …
import { BehaviorSubject } from 'rxjs';

creating obseravbles

Before RxJS 6 we had many ways to create an observable (.create, of, …). Now there is only of:

import { of } from 'rxjs';

of([ 1, 2, 3 ])
 .subscribe(val => //…)

whats more?

There is a lot more! Head over to https://github.com/ReactiveX/rxjs/blob/master/MIGRATION.md for the full migration guide.

Four things you should know when updating to RxJS 6 was originally published in EcoLogic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our customer is not interested in inserting external images to a text but wants to chose from the images already uploaded to Directus. There is an image list which can be enabled in the column settings of the table. Go to the column settings -> interface options and scroll down.

Unfortunately this basic image list does only show a list of titles. Our customer wants to see thumbnails for images. So we replaced the standard image plugin of the bundled tinyMce editor with a custom one. This plugin looks like this:

When you click on an image it gets sent to the editor:

To use the custom plugin, simply copy over plugin.min.js and styles.css from github to assets/js/vendor/tinymce/plugins/image. Enable the ‘image’ plugin in app/core/interfaces/wysiwyg_full/interface.js. Thats it.

Thats it. The repository is https://github.com/EcoLogicAG/tiny-images

To use the plugin as an additional plugin one could rename the plugin (and the button and menu identifier) and add it as an new plugin in app/core/interfaces/wysiwyg_full/interface.js (Needs to be added to the plugins and the toolbar properties.)

Simplified Image Dialog for TinyMCE in Directus was originally published in EcoLogic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Integrating AutoMapper with ASP.NET Core DI

To use localization in AutoMapper we had to basically change three lines of code in Startup.cs and install the AutoMapper.Extensions.Microsoft.DependencyInjection NuGet package.

var config = new MapperConfiguration(cfg => { cfg.AddProfile(new AutoMapperConfig()); });
services.AddSingleton(sp => config.CreateMapper());

Becomes:

services.AddMvc();
services.AddAutoMapper(typeof(Startup));

It is important to note that `services.AddAutoMapper()` has to be called after `services.AddMvc()`.

You don’t need to supply AutoMapper with your profiles anymore. AutoMapper will search the assemblies to initialize itself. All resolvers will be registered in the DI container of .NET Core by AutoMapper.

You can now use the localizer in your profile:

public class AutoMapperConfig : Profile
{
    public AutoMapperConfig()
    {
        CreateMap<Model, ViewModel>()
            .ForMember(dest => dest.Titel, opt => opt.ResolveUsing<TranslateResolver, string>(src => src.Titel));
    }

public class TranslateResolver : IMemberValueResolver<object, object, string, string>
    {
        private readonly IStringLocalizer<TranslateResolver> _localizer;

public TranslateResolver(IStringLocalizer<TranslateResolver> localizer)
        {
            _localizer = localizer;
        }
        
        public string Resolve(object source, object destination, string sourceMember, string destMember,
            ResolutionContext context)
        {
            return _localizer[sourceMember];
        }
    }
}

Using Localization in AutoMapper with .NET Core was originally published in EcoLogic on Medium, where people are continuing the conversation by highlighting and responding to this story.