WP Job Openings - Frontity Package

anantajitjg · 6 July 2020 09:49

Frontity package for WP Job Openings plugin. This package enables the support for application form provided by the WP Job Openings plugin. All the default fields and the fields supported by Pro version are supported.

We have made this package for our company’s new website as we need to integrate the careers page with our own job listing WordPress plugin – WP Job Openings. There were some challenges during the development of the package. But, with the help of Frontity Team and Frontity Contact Form 7 package, this package was successfully created and published to NPM. Please suggest improvements or any issues(if any) and provide feedback on this package.

Demo

Job Detail Page (Mars Theme)

Application View (WordPress)

luisherranz · 6 July 2020 11:48

I love it! And this is something we could easily use in the future for our own careers section!

I’ve been reviewing the code. Congratulations, it looks amazing.

There are some things that are not obvious yet in Frontity. This is our fault because there are no docs yet on that. But let’s see what things can be improved

1. Make the repo a Frontity project

Our recommendation is make the repo of the package (https://github.com/awsmin/frontity-wp-job-openings) a Frontity project itself. The main reason is that, if people wants to collaborate:

Cloning the repo.
Creating a Frontity project.
Installing the package using npm link.
Configuring the project and the package.
Running npx frontity dev.

it’s much more difficult than:

Cloning the repo.
Running npx frontity dev.

You can use mars-theme and I guess you could use your own demo site as the backend.

More on that approach here: https://docs.frontity.org/guides/how-to-share-a-frontity-project

2. Add the needed custom post types

I see that in your instructions you’re asking people to add the awsm_job_openings custom post type: https://github.com/awsmin/frontity-wp-job-openings#setup

Package can add any state that they need, even for other namespaces, so you can avoid that installation step by adding that state yourself in your package:

export default {
  name: "@awsmin/frontity-wp-job-openings",
  state: {
    awsmjobs: {
      ajaxurl: "",
      forms: {},
    },
    source: {
      postTypes: [
        {
          type: "awsm_job_openings",
          endpoint: "awsm_job_openings",
          archive: "/jobs",
        },
      ],
    },
  },
  // ...
};

3. Add a setting for the redirection

The same happens with the redirection. If your WP plugin needs that code, you can add it yourself in your package:

const jobsRedirect = {
  name: "awsm_job_openings",
  pattern: "/jobs/:slug",
  func: ({ slug }) => `/awsm_job_openings/${slug}/`,
};

export default {
  name: "@awsmin/frontity-wp-job-openings",
  // ...
  libraries: {
    source: {
      redirections: [jobsRedirect],
    },
  },
};

If the slug can be configured in your WP plugin, then maybe you can add a setting to your package.

const jobsRedirect = (name) => ({
  name: "awsm_job_openings",
  pattern: `/${name}/:slug`,
  func: ({ slug }) => `/awsm_job_openings/${slug}/`,
});

export default {
  name: "@awsmin/frontity-wp-job-openings",
  state: {
    awsmjobs: {
      ajaxurl: "",
      forms: {},
      slug: "jobs",
    },
  },
  actions: {
    init: ({ state, libraries }) => {
      libraries.source.redirections.push(jobsRedirect(state.awsmjobs.slug));
    },
  },
};

And instruct people that if they have changed the slug, they need to add a setting on their frontity.settings.js file:

const settings = {
  // ...
  packages: [
    {
      name: "@awsmin/frontity-wp-job-openings",
      state: {
        awsmjobs: {
          slug: "careers",
        },
      },
    },
    // ...
  ],
};

This way, the package can be a zero-configuration package, except when people have changed the slug

4. Use low priority for your processors

I see right now you’re not using the priority field on the processors. That means that if other package, for example a theme, is trying to target the same nodes with processors to change their style, there’s no warranty that your processors will run the last ones.

I think it’s a good practice to set a priority of 20 for processors like yours that replace the HTML node with a React component.

That way, if someone is using processors for styles, they will be applied first (default priority is 10):

import { css } from "frontity";

export const styleInputs = {
  name: "style inputs",
  test: ({ node }) => node.component === "input",
  processor: ({ node }) => ({
    ...node,
    props: {
      ...node.props,
      css: css`
        ${node.props.css}
        width: 38px;
        border-radius: 11px;
      `,
    },
  }),
};

5. Do not duplicate input values

I see you are also duplicating the input props, like Imran and Smit did on the Frontity Contact Form 7 package:

github.com

awsmin/frontity-wp-job-openings/blob/master/src/processors/form/input-fields.js#L7-L15


node.props.inputProps = {
    name: node.props.name,
    className: node.props.className,
    type: node.props.type,
    id: typeof node.props.id !== 'undefined' ? node.props.id : '',
    value: typeof node.props.value !== 'undefined' ? node.props.value : '',
    accept: typeof node.props.accept !== 'undefined' ? node.props.accept : '',
    ariaRequired: typeof node.props['aria-required'] !== 'undefined' ? node.props['aria-required'] : ''
};

I never find out what was the reason to do that, but I don’t think it’s needed. Those fields should be already preesnt in the node. For example, once you remove that, you can get the props like this:

// Use this:
const Input = ({ state, actions, ...props }) => {
  const jobId = useContext(FormIdContext);
  const fileInput = React.useRef();

  // Use the values:
  props.name;
  props.type;
  props.value;
};

// Instead of this:
const Input = ({ state, actions, inputProps }) => {
  const jobId = useContext(FormIdContext);
  const fileInput = React.useRef();

  // Use the values:
  const inputName = inputProps.name;
  const inputType = inputProps.type;
  const inputValue = inputProps.value;

  // ...
};

And avoid the need to do this in your processors:

node.props.inputProps = {
  name: node.props.name,
  className: node.props.className,
  type: node.props.type,
  // ...
};

If while removing them you find any problem let me know and we’ll figure out a solution.

6. Use the connect hook: `useConnect`

It looks like you are creating an object of props to pass it down to the input, at:

github.com

awsmin/frontity-wp-job-openings/blob/master/src/components/form/input.js#L36-L43


let componentProps = {
    type: inputType,
    name: inputName,
    className: inputProps.className,
    id: inputProps.id,
    'aria-required': inputProps.ariaRequired,
    onChange: onChangeHandler
};

You can avoid that if instead of using connect to get the state, you use useConnect and add { injectProps: false } to connect, like how we explain here: https://docs.frontity.org/api-reference-1/frontity#use-case-of-injectprops-false-with-connect

That way, you can get the props and pass the down:

const Input = (props) => {
  const { state, actions } = useConnect();

  const jobId = useContext(FormIdContext);
  const fileInput = React.useRef();

  // ...
  return <input {...props} />;
};

export default connect(Input, { injectProps: false });

This is safer and requires less code

7. CORS

The CORS issue is a shame, there’s not much we can do here. It will be solved once we release the Embedded Mode and the domain of Frontity matches the domain of WordPress though. More info on: Embedded mode

anantajitjg · 6 July 2020 12:04

Wow! Lots of great suggestions here. I will go through these suggestions one by one and apply the same on the package.
Thank you very much for the guidance @luisherranz

anantajitjg · 9 July 2020 17:46

Version 1.1.0 of WP Job Openings - Frontity Package released, including all of the above suggestions.

CHANGELOG

This was not working. So, I had to change it to this (with the namespace of awsmjobs):

actions: {
    awsmjobs: {
      init: ({ state, libraries }) => {
        libraries.source.redirections.push(jobsRedirect(state.awsmjobs.slug));
      },
      ...formActions,
    },
  },

Please correct me if I am wrong.

Thanks again @luisherranz. Thanks for the amazing support.

luisherranz · 13 July 2020 08:33

Yes, good catch

Awesome work! The package is now a “zero-config package”

Some other things/thoughts:

Mars theme

Have you modified mars-theme? If not, you can move it from /packages to /node_modules. Just delete the folder and add the version in the package.json file just like any other npm package. That way, the repository is cleaner and the only local package is your own package.

EDIT: Oh, I see you have because you added the job post type to the list. Don’t worry then.

CodeSandbox

I made a PR to add the CodeSandbox config file. That way people can run this project in CodeSandbox, like this one from my fork:

https://githubbox.com/luisherranz/frontity-wp-job-openings/tree/codesandbox

CORS

I was thinking about the CORS issue. Maybe after we release the official Frontity WordPress plugin, which will contain a setting to set the URL of the site, you could do this in your PHP plugin:

Detect if the Frontity WordPress plugin is activated.
If it is, get the URL of the Frontity server and add CORS for it, like what you explain here: https://github.com/awsmin/frontity-wp-job-openings#cors-issue

anantajitjg · 13 July 2020 09:51

Yes!!! Now, it is super easy to setup.

I have merged the PR. I didn’t know that configuring the codesandbox template is that easy for the Frontity project. Thanks a lot.

Amazing! Once the Frontity WordPress plugin is released we will implement this in our plugin.

A Big thanks to whole Frontity Team for this awesome framework.