Giters

bu-ist / coding-standards

Code style guides for web projects at Boston University.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Research: Non-Block JS Coding Standards & Linting

timkingbu opened this issue · comments

commented

Research Topics:

  • We should define best practices for writing/linting/building JS.

Explorations:

Findings:

...tbd

Frontend Considerations:

Backend Considerations:

  • Wordpress is "hog-tied" to React

Examples

commented

@timkingbu Are we thinking for custom JS, that we will need to create for client projects or are we discussing the JS that will be written to create blocks for the visual editor? If the later, I think that we default to the standards that WordPress uses already. If the former (custom JS for client projects) I think that we can table that BUT certainly we should create an issue for it so that we can delineate the difference between the 2.

@hirozed @alana29s @dakota do any of you have any feedback on this?

commented

@smtierneybu I was thinking the former. I avoided jquery in the FitRec hours project, but the GradEd program filter already had it, so I used it there.

commented

I'm not sure how far we could go with this, seeing how Gutenberg is hog tied to React, but I'm a fan of using as much vanilla JavaScript as possible. I feel going that route future proofs the code. JQuery specifically, while still bundled with WP, was there as a crutch when modern JS wasn't as feature rich. Reducing the reliability on that library, within core or not, would help in the long run.

commented

I've written my fair share of JS over the years and for the past five years or so I've been making an effort myself to move away from relying on jQuery or similar libraries where appropriate and writing more vanilla javascript.

For the Prepress and BU Blocks plugins I wrote most of the frontend JS for those and it was I think mostly all vanilla JS. I'm working on this issue https://github.com/bu-ist/id-gutenberg/issues/43 about Frontend JS for blocks and will add some thoughts based on that experience.

I do think vanilla JS would be ideal for javascript in plugins for the frontend JS for a Collapsible or Slideshow block. I'd avoid jQuery for the frontend JS for a gutenberg block in a plugin. Some plugins might be complex enough that it warrants React or some other more sophisticated library.

For client themes I still see a role for jQuery for the light and simpler stuff, especially areas where a designer might be able to jump in to handle some animations or light interactivity. If we build blocks in a child theme for a specific client need I'd probably lean toward vanilla js for the frontend JS of that block, and maybe allow jQuery if it was relatively simple. For example let's say we were building a custom callout block of some type in a child theme and it had a simple hover animation. I would be okay with seeing jQuery used for that. I might point out how it could be done with vanilla JS but it would be acceptable up to a point. There is however I think a point where jQuery and the style of JS that jQuery encourages you to write just doesn't scale well.

For something more complicated like the At a Glance Component in Fitrec the way you approached it @timkingbu with vanilla JS seemed right to me for something more complex like that with the need for more state management. If that was being built as a Gutenberg Block I think vanilla JS for the frontend 100%.

For non-block frontend JS in a plugin my preference would be vanilla JS by default unless there was a specific need to adopt something more complex like React. Like @hirozed said it just future proofs it more IMO and is less to maintain.

I don't know that I would want to enforce a specific JS pattern, but maybe we could recommend one or two patterns that we like the best? For small-ish things I tend to favor the Object Literal Singleton pattern I believe it is called? Sort of like this audio player control layer.

commented

Here's an example of how I organized and wrote the vanilla JS for the frontend of the BU Stories plugin: https://github.com/bu-ist/bu-stories/tree/develop/src/js/frontend. I opted to separate it into smaller components and import them to keep concerns separated and organized.

commented

wp-scripts has built a in linter wp-scripts lint-js and fixer wp-scripts lint-js --fix

It uses eslint with the set of recommended rules defined in @wordpress/eslint-plugin npm package. You can override default rules with your own as described in eslint docs. Learn more in the Advanced Usage section.