Сохранение настроек пользовательского блока WordPress в редакторе блоков PlatoBlockchain Data Intelligence. Вертикальный поиск. Ай.

Сохранение настроек пользовательского блока WordPress в редакторе блоков

Мы сделали кучу вещей в этой серии! Мы создали собственный блок WordPress, который извлекает данные из внешнего API и отображает их во внешнем интерфейсе. Затем мы взяли эту работу и расширили ее, чтобы данные также отображались непосредственно в редакторе блоков WordPress. После этого мы создали UI настроек для блока, используя компоненты из WordPress. InspectorControls пакет.

Остался последний момент, который мы должны рассмотреть, и это сохранение параметров настроек. Если вспомнить из прошлой статьи, технически мы можем «сохранить» наши выборки в пользовательском интерфейсе настроек блока, но на самом деле они нигде не хранятся. Если мы делаем несколько выборок, сохраняем их, затем возвращаемся к посту, настройки полностью сбрасываются.

Давайте закроем цикл и сохраним эти настройки, чтобы они сохранялись в следующий раз, когда мы редактируем сообщение, содержащее наш пользовательский блок!

Работа с внешними API в блоках WordPress

Сохранение атрибутов настроек

Мы работаем с API, который предоставляет нам футбольный рейтинг футбольных команд, и мы используем его для отображения рейтингов в зависимости от страны, лиги и сезона. Мы можем создать новые атрибуты для каждого из них, например:

// index.js

attributes: {
  data: {
    type: "object",
  },
  settings: {
    type: "object",
    default: {
      country: {
        type: "string",
      },
      league: {
        type: "string",
      },
      season: {
        type: "string",
      },
    },
  },
},

Далее нам нужно установить атрибуты из LeagueSettings.js. Всякий раз, когда ComboboxControl обновляется в нашем пользовательском интерфейсе настроек, нам нужно установить атрибуты, используя setAttributes() метод. Это было проще, когда мы работали только с одной конечной точкой данных. Но теперь, когда у нас есть несколько входных данных, это немного сложнее.

Вот как я собираюсь это организовать. Я собираюсь создать новый объект в LeagueSettings.js который соответствует структуре атрибутов настроек и их значений.

// LeagueSettings.js

let localSettings = {
  country: attributes.settings.country,
  league: attributes.settings.league,
  season: attributes.settings.season,
};

Я также собираюсь изменить начальные переменные состояния с null к соответствующим переменным настроек.

// LeagueSettings.js

const [country, setCountry] = useState(attributes.settings.country);
const [league, setLeague] = useState(attributes.settings.league);
const [season, setSeason] = useState(attributes.settings.season);

В каждом из handle______Change(), я собираюсь создать setLocalAttributes() который имеет аргумент, который клонирует и перезаписывает предыдущий localSettings объект с новыми значениями страны, лиги и сезона. Это делается с помощью оператора спреда.

// LeagueSettings.js

function handleCountryChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, country: value });
  // Rest of the code
}

function handleLeagueChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, league: value });
  // Rest of the code
}

function handleSeasonChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, season: value });
  // Rest of the code
}

Мы можем определить setLocalAttributes() как это:

// LeagueSettings.js

function setLocalAttributes(value) {
  let newSettings = Object.assign(localSettings, value);
  localSettings = { ...newSettings };
  setAttributes({ settings: localSettings });
}

Итак, мы используем Object.assign() объединить два объекта. Затем мы можем клонировать newSettings возражать обратно к localSettings потому что нам также необходимо учитывать каждый атрибут настроек, когда делается новый выбор и происходит изменение.

Наконец, мы можем использовать setAttributes() как мы обычно делаем, чтобы установить конечный объект. Вы можете убедиться, что вышеуказанные атрибуты изменяются, обновив выбор в пользовательском интерфейсе.

Другой способ подтвердить — выполнить console.log() в DevTools, чтобы найти атрибуты.

Сохранение настроек пользовательского блока WordPress в редакторе блоков

Посмотрите внимательнее на этот скриншот. Значения хранятся в attributes.settings. Мы можем увидеть, как это происходит вживую, потому что React перерисовывает каждый раз, когда мы вносим изменения в настройки, благодаря useState() крюк.

Отображение значений в пользовательском интерфейсе настроек блоков

Не очень полезно хранить значения настроек в самих параметрах управления, поскольку каждое из них зависит от другого значения настройки (например, ранжирование по лиге зависит от того, какой сезон выбран). Но это очень полезно в ситуациях, когда значения настроек статичны и когда настройки не зависят друг от друга.

Не усложняя текущие настройки, мы можем создать еще один раздел внутри панели настроек, который показывает текущие атрибуты. Вы можете выбрать свой способ отображения значений настроек, но я собираюсь импортировать Tip компонент из @wordpress/components пакет:

// LeagueSettings.js
import { Tip } from "@wordpress/components";

Пока я здесь, я собираюсь выполнить условную проверку значений, прежде чем отображать их внутри Tip компонент:


  {country && league && season && (
    
      

Current Settings:

Country: {attributes.settings.country}
League: {attributes.settings.league}
Season: {attributes.settings.season}
)}

Вот как это работает в редакторе блоков:

Данные API более эффективны, когда данные в реальном времени можно отображать без необходимости каждый раз обновлять их вручную. Мы рассмотрим это в следующем выпуске этой серии.

Отметка времени:

Больше от CSS хитрости