A recent Vokal project involved redesigning and rethinking a Web site for a client that has a large library of content. We opted for a headless-CMS architecture, an increasingly popular approach that delivers fast performance for the visitor and a flexible, maintainable coding experience for the developer.
Vokal最近的一个项目涉及为具有大量内容库的客户重新设计和重新考虑网站。 我们选择了无头CMS架构，这是一种越来越流行的方法，可以为访问者提供快速的性能，并为开发人员提供灵活，可维护的编码体验。
For the CMS we chose Prismic. I found that this snappy, easy-to-use service has about 85% of the features I want from a CMS. Just as important, it has 0% of the features I don’t want.
对于CMS，我们选择Prismic 。 我发现，这个简单易用的服务具有我想要的CMS功能的约85％。 同样重要的是，它具有我不想要的功能的0％。
Overall the Prismic experience was excellent, but in the 15% of “missing” features the biggest hole is this: There is no validation within its editor.
总体而言，Prismic的体验非常出色，但是在“缺失”功能的15％中，最大的漏洞是：编辑器中没有验证。
Fields cannot be made to be required, nor can they be constrained within certain rules. There’s not even the ability to add helper text to guide editors towards valid content entry. Prismic has thoughtful reasons for not including validation, but I still feel this choice is a net loss for the editor.
不能使字段成为必需字段，也不能将它们限制在某些规则内。 甚至没有添加助手文本来引导编辑器进行有效内容输入的功能。 Prismic有一些不考虑验证的深思熟虑的原因 ，但我仍然觉得这种选择对编辑人员来说是一笔净亏损。
Without the ability to make fields required, the front-end developer will need to evaluate every field in all of a project’s various content models and decide what should happen if the editor leaves it blank. It’s a drag, but the upside is your app will end up more robust and bomb-proof.
如果没有能力使字段成为必需，则前端开发人员将需要评估项目所有各种内容模型中的每个字段，并确定如果编辑器将该字段留为空白该怎么办。 这是一个阻力，但好处是您的应用程序最终将变得更强大且更安全。
For example, let’s say you have a document that includes a special link component as a slice. This component has four fields: a headline, some body copy, text for a button, and a link.
例如，假设您有一个包含特殊链接组件作为切片的文档。 该组件具有四个字段：标题，某些正文，按钮的文本和链接。
In a React app, the front-end implementation might look something like this:
在React应用程序中，前端实现可能看起来像这样：
const Refer = ({
headline, body, link, link_text
}: any) => (
<aside>
<h1>{headline}</h1>
<p>{body}</p>
<a href={link}>{link_text}</a>
</aside>
);
export default Refer;Uh-oh — an editor has forgotten to include a link and gone ahead and published her page. What will happen? In certain situations it might crash the app. Our humble component here will render just fine, thankfully enough, but since link is undefined (or possibly null, depending on how you route data from the Prismic API to your component), the anchor element will have no href property. When viewing the page the editor probably won’t even notice—until she gets an angry call from a stakeholder about a broken link.
嗯-一位编辑忘记了添加链接，然后继续发布了她的页面。 会发生什么？ 在某些情况下，它可能会使应用程序崩溃。 值得庆幸的是，我们这里的不起眼的组件将很好地呈现，但是由于未定义link (或可能为null，具体取决于您如何将数据从Prismic API路由到组件)，所以anchor元素将没有href属性。 在查看页面时，编辑者甚至可能不会注意到-直到她收到利益相关者关于链接断开的愤怒呼叫。
As I build front ends for my Prismic components, I consider how critical each field is to the component as a whole. (When in doubt, I consult my designer or product manager.) For each field, I decide on one of three outcomes in the event of its absence:
在为Prismic组件构建前端时，我考虑了每个字段对于整个组件的重要性。 (如果有疑问，请咨询我的设计师或产品经理。)对于每个领域，如果没有该领域，我将决定三个结果之一：
- The page renders without the component. 页面呈现时没有组件。
- The component renders, but without the missing field. 组件将呈现，但没有缺少的字段。
- The component renders with a fallback for the missing field. 该组件将对缺少的字段进行回退。
In this case, the link is pretty critical. My designer tells me the headline should be required, too. Thus if either of those is missing, I will allow the page to render but without this component. The body text, however, is expendable. The link text is not critical either, but the link needs something, so I’ll provide a generic fallback.
在这种情况下，链接非常关键。 我的设计师告诉我，标题也是必需的。 因此，如果缺少任何一个，我将允许页面呈现但没有此组件。 但是，正文是消耗性的。 链接文本也不重要，但是链接需要一些东西 ，因此我将提供一个通用的备用。
To do this, I revise my component to something like this:
为此，我将组件修改为以下形式：
const Refer = ({
headline, body, link, link_text
}: any) => {
if (!headline || !link) {
return null;
}
return (
<aside>
<h1>{headline}</h1>
{body && <p>{body}</p>}
<a href={link}>{link_text || 'Learn more'}</a>
</aside>
);
};
export default Refer;This takes care of the front end—but what about the editing experience? How can we bring errors to the editor’s attention? For this, I created a special error component in React.
这会照顾到前端，但是编辑体验又如何呢？ 如何使错误引起编辑注意？ 为此，我在React中创建了一个特殊的错误组件。
const EditorAlert = ({ block, children }) => {
const { isStaff } = useContext(AuthContext);
if (!isStaff) {
return null;
}
if (block) {
return <div className="editor-alert">{children}</div>;
}
return <span className="editor-alert">{children}</span>;
};
export default EditorAlert;The use of isStaff and useContext is a bit out of this discussion’s scope, but suffice to say the value of isStaff is set by looking for the presence of a cookie named io.prismic.preview, which gets set when an editor views the site in preview mode. If this cookie is present, it indicates the user is an editor and should thus see error messages. (This is an imperfect proxy. Ideally Prismic’s cookies could tell us more about the visitor, such as their role or privileges.)
isStaff和useContext的使用不在本讨论的讨论范围之内，但是足以说出isStaff的值是通过查找是否存在名为io.prismic.preview的cookie来设置的，该cookie在编辑者查看站点时被设置。预览模式。 如果存在此cookie，则表明用户是编辑者，因此应看到错误消息。 (这是不完美的代理。理想情况下，Prismic的cookie可以告诉我们有关访客的更多信息，例如访客的角色或特权。)
Elsewhere I use CSS to make these error messages intentionally garish—red type, dotted red borders—to help ensure they grab the editor’s attention.
在其他地方，我使用CSS故意使这些错误消息(红色字体，红色虚线框)突出，以帮助确保它们引起编辑者的注意。
Putting it all together, my final component looks like this:
放在一起，我的最终组件看起来像这样：
const Refer = ({
headline, body, link, link_text
}: any) => {
if (!headline) {
return (
<EditorAlert block>
Your refer component is missing a headline, which is required.
</EditorAlert>
);
}
if (!link) {
return (
<EditorAlert block>
Your refer component is missing a link, which is required.
</EditorAlert>
);
}
return (
<aside>
<h1>{headline}</h1>
{body
? <p>{body}</p>
: (
<EditorAlert>
<p>
The style guide suggests some body text here, but it’s not required.
</p>
</EditorAlert>
)}
<a href={link}>{link_text || 'Read more'}</a>
</aside>
);
};
export default Refer;Now I’ve met my primary goals: Components will fail gracefully if fields are unpopulated, and just as important, the editors will get useful feedback when there are errors.
现在，我已经实现了我的主要目标：如果不填充字段，组件将无法正常运行，同样重要的是，当出现错误时，编辑器将获得有用的反馈。
Here is how our component would now look, depending on the fields entered and who is viewing it:
这是我们的组件现在的外观，具体取决于输入的字段和查看者：
Fixing these errors will still hinge on the editors actually previewing their pages before publication. If they’re not doing this, you still have a problem—but it’s a problem with your editorial workflow, not your tech stack.
修复这些错误仍将取决于编辑者在发布之前实际预览其页面。 如果他们没有这样做，您仍然会遇到问题-但这是您的编辑工作流程而不是技术堆栈的问题。
I’ve focused on blank fields here, but you may want to perform other validations, too, including some that might not be possible with most CMS validators. For example, if a document has fields for start and end dates, you may want to verify that the end date is after the start date. Or if your component has a hero image, you may want give the editor a warning if the image’s dimensions are too small.
我在这里专注于空白字段，但是您可能还想执行其他验证，包括大多数CMS验证程序可能无法进行的验证。 例如，如果文档具有开始日期和结束日期字段，则您可能需要验证结束日期是否在开始日期之后。 或者，如果您的组件具有英雄图像，则如果图像的尺寸过小，则可能要向编辑器发出警告。
I have no regrets about using Prismic for this project, and I wouldn’t hesitate to use it again. If a project absolutely required in-editor validation, however, I would probably turn to CraftCMS or Contentful, depending on the project’s needs.
对于在这个项目中使用Prismic，我没有任何遗憾，并且我会毫不犹豫地再次使用它。 但是，如果一个项目绝对需要编辑器中的验证，我可能会根据项目的需求转向CraftCMS或Contentful 。
翻译自: https://medium.com/vokal-voices/prismic-field-validation-3ebf33ffdd6
扫一扫
790
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
