React support?

[hogarthww-labs]

What would it take to add support for react? Where are the main places to change the current generators etc?

I've been browsing through the code and see the following potential changes/modifications:

export enum Language {
  Angular = 'ng',
}

Which could obviously be changed to Framework and React added as a value

export enum Framework {
  Angular = 'ng',
  React = 'react'
}

create-app

export const isAppFolderExisting = (framework: string, tree: Tree): boolean => {
  return tree
    .children('libs')
    .some((appGroupingFolder) =>
      appGroupingFolder.startsWith(framework)
    );
};

FE app generator

  const { framework, name, baseFolder } = options;
  if (!isAppFolderExisting(framework, tree)) {
    await initialiseAngularWorkspace(tree);
  }

To initialise FE framework workspace

export const initialiseFrameworkWorkspace = (tree: Tree): GeneratorCallback => {
  addEslintLayerConstraints(tree);
  return addDependencies(tree);
};

create-domain

leave unchanged

move

leave unchanged

remove

leave unchanged

ng-add

leave unchanged

react-add

export async function reactAddGenerator(tree: Tree) {
  return addDependenciesToPackageJson(
    tree,
    {},
    {
      '@nrwl/react': 'latest',
      '@nrwl/cypress': 'latest',
    }
  );
}
export default reactAddGenerator;

export const reactAddSchematic = convertNxGenerator(reactAddGenerator);

shared

leave unchanged

src/generators

component

Change to ng-component

react-component

Copy ng-component folder

• Modify files to have a single tsx file and perhaps a .spec.tsx file
• Remove lib and model folders
• Modify generator.ts accordingly

create (create new generator)

leave unchanged

libraries

Modify generator.js slightly to adjust for react framework option

const normalizeOptions = (
  options: LibrariesGeneratorSchema
): LibrariesNormalizedSchema => {
  return {
    ...options,
    libraryDefinitions: getDomainLibraryDefinitions(
      options.application,
      options.domain,
      options.libraries,
      options.framework // support diff FE frameworks
    ),
  };
};

import { wrapAngularDevkitSchematic } from '@nrwl/devkit/ngcli-adapter';
import { wrapReactDevkitSchematic } from '@nrwl/devkit/react-adapter';

const devKitSchematicFrameworkMap = {
  angular: wrapAngularDevkitSchematic,
  react: wrapReactDevkitSchematic
}

  const wrapDevkitSchematic = devKitSchematicFrameworkMap[options.framework]
  const libraryGenerator = wrapDevkitSchematic(
    `@nrwl/${options.framework}`,
    'library'
  );

... leave the rest mostly unchanged it seems

[srleecode]

I am rewriting the generators at the moment. packages\domain\src will eventually be removed and the content in packages\domain\generators will be what is exposed. My current plans are described here: https://github.com/srleecode/domain/tree/master/documentation/next if you have any thoughts on it I would be interested in hearing them.

Most generators should be easy to update to allow react support as well. The main one to think about is the component generator. I would need your help to define the best approach in regards to this generator. What is the best way in react for cypress component testing, can you mount storybook stories and is there a react version of component test harnesses. If there is none, then maybe it should use https://github.com/srleecode/component-command-utils

[hogarthww-labs]

Hi @srleecode

Thanks for your swift reply. I will add my thoughts on component generator for React.

- src/components/Task
 + index.js
 + Task.js
 + Task.spec.js
 + Task.stories.js
 + Task.scss (depending on style lib chosen for Nx)

Component file

// src/components/Task/Task.js
import React from 'react';

export default function Task({ title }) {
  return (
    <div className="list-item">
      <input type="text" value={title} readOnly={true} />
    </div>
  );
}

// src/components/Task/index.js
export * from './Task'

Spec file (using enzyme) (when additional option --test-dom-manager is enzyme)

// src/components/Task/Task.spec.js

    import React from 'react';
    import { shallow } from 'enzyme';
    import Task from './Task';

    describe('Task component', () => {
      it('renders', () => {
        const wrapper = shallow(<Task />);
        expect(wrapper).toMatchSnapshot();
      });
    });

Test file (when additional option --test-dom-manager is react-test-renderer)

// src/components/Task/Task.spec.js

import React from 'react';
import renderer from 'react-test-renderer';
import Task from './Task';

test('Task renders', () => {
  const component = renderer.create(
    <Task />
  );
  let tree = component.toJSON();
  expect(tree).toMatchSnapshot();
})

Storybook

// src/components/Task/Task.stories.js
import React from 'react';

import Task from './Task';

export default {
  component: Task,
  title: 'Task',
};

const Template = args => <Task {...args} />;

export const Default = Template.bind({});
Default.args = {title: 'Test Task'};

Storybook config

.storybook/main.js
module.exports = {
  stories: ['../src/components/**/*.stories.js'],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/preset-create-react-app',
  ],
};

[srleecode]

A few points:

• Where possible it would be good if we can use existing generators internally, so that it is easier for them to be kept up to date. For creating the component, can this be used: https://github.com/nrwl/nx/tree/master/packages/react/src/generators/component
• The plan is to move away from having a storybook project for each domain. Instead component testing would be used. This means that each component would have its own library that would have its own component testing setup. This looks like what the generators should do https://www.cypress.io/blog/2021/04/06/cypress-component-testing-react/. The questions I have are:
  • Is there a generator already to create this?
  • Is there a way to mount stories instead of components?
• When it comes to the cypress testing, it is normally done on two different levels. There are the UI/interaction tests that can be done through storybook tests or through using the cypress component test harness. There are then the E2E tests. These two different types of tests run at different stages in the software development process. The UI/Interaction tests can run earlier in the CI stage whereas the E2E tests need to often be run later after the deploy stage. Using something like component test harnesses or the custom component commands means that your component end up with apis that are tested in the CI stage. This means that there is no duplication in things like selectors between the UI/interaction and E2E tests. It also means that your E2E tests won’t break due to dom changes and broken selectors as these issues will be picked up in the CI stage through the UI/interaction tests. I am not sure if react has anything like the component test harnesses, so maybe the custom component commands need to be used.

[hogarthww-labs]

Thanks @srleecode :) I completely agree on all your points. This PR was mainly just a starting point to have something to discuss around. A very rough draft.

• Definitely use existing generators where possible
• I love having a library per component, exactly how I prefer it. I hate monolith approach. Let's create a generator which includes cypress component testing for each component and so on...
• Yes, E2E should be done at multiple levels. I love your general idea, also in relation to different stages of CI. Exactly what we are aiming to achieve in the company I work for.

Couldn't agree more. 💯% on point 🚀

[srleecode]

I appreciate your input and the PR (#21). I will close it as I think we got what we wanted out of it.

I made the following changes after going through the pr:

• added the react-add generator
• updated Language to ApplicationType in the create app grouping folder generator

Next step with react is to implement the component generator. Is this something you would be willing to look at and contribute?

I am currently thinking it should:

• create a library using https://github.com/nrwl/nx/tree/master/packages/react/src/generators/library
• create a component using https://github.com/nrwl/nx/tree/master/packages/react/src/generators/component
• Implement cypress component testing for the library so that it has something like this https://www.cypress.io/blog/2021/04/06/cypress-component-testing-react/
  • Implement something like a component test harness, e.g. https://github.com/srleecode/component-command-utils if there is nothing better.

Once that generator is created then we should know what needs to be installed and setup globally for react and a initaliaseReactWorkspace function can be written here https://github.com/srleecode/domain/blob/98932d76df41e521fb7d69a9f2667f2b428a21cf/packages/domain/generators/grouping-folder/create-app/src/lib/shared/initialise-workspace.ts#L6 The other generators should all either not need a specific one for each application type or be easy to create react versions for them.

[hogarthww-labs]

I would be happy to try implementing the component generator using the recipe you've outlined. I think I would have time next week (end of August)

[srleecode]

That would be great. Since there are still a lot of things that need to be investigated. I think it would be a good idea for you to create a new very simple project that has two components and one component that uses the others api from something like a component test harness in its test. Once that simple project is setup we will know what to generate. It should also allow mounting stories

[srleecode]

I am closing this as there has been no response. @hogarthww-labs if you are still interested in this storybook interaction testing is still in alpha, but it will allow interaction testing https://github.com/srleecode/domain/issues/40 . This resolves the uncertainty mentioned in the above comment and the approach for react is now known . If you are interested let me know and we can reopen this or create a new ticket.