I have a simple singleton document schema defined in my Sanity/NextJS project, to model my "Colophon" page (richText is a custom block field type):
export default {
title: 'Colophon',
name: 'colophon',
type: 'document',
__experimental_actions: ['update', 'publish'],
fields: [
{
title: 'Body',
name: 'body',
type: 'richText',
validation: Rule => Rule.required(),
},
],
};
I retrieve this document with a simple query in my NextJS application:
export async function getStaticProps() {
const colophon = await client.fetch(`
*[_type == "colophon"][0]
`);
// ...
};
Is it possible to write a GROQ query to retrieve the meta title defined in the schema, i.e. Colophon? Although this is a singleton document, I would like to avoid repeating this string in my project if possible. At the moment, I can only see the fields on the document in my results, i.e. body.
Thanks for reading!
No, I don't believe there is.
As far as I understand what you're after; The schema is defined in the studio-instance and not the datastore. Those two are not hard coupled. I have several studio-instances with small variations on the schemas using one single project/datastore. The API you query to get data does not care which studio and schema was used and cant answer for the actual schema details.
Related
A user is allowed to create items, optionally add up to 10 tags. There's going to be a tag cloud on one of the pages, so storing them in a separate collection seems justified.
The Tag schema is modeled as following:
module.exports = mongoose.model("Tag", new mongoose.Schema({
label: {
type: String,
required: true,
lowercase: true,
maxLength: 35
}
}));
The Item schema has a tags key which references documents in Tag:
tags: {
type: [{ type: ObjectId, ref: "Tag" }],
validate: {
validator: n => n <= 10
}
},
Now, it would be easier to just store tags as subdocuments inside each item but as I said, I'll have a tag cloud later. Reading them from the items collection just to render the tag cloud will probably be a bit expensive, so duplicating them seems almost necessary and the lesser of the two devils. Please correct me if I'm wrong.
Anyway, the main question is: how do I add tags in this scenario then? The request content will be a JSON object, sent to /api/collections/items with the POST method. How can I make sure tags are added to both collections and the limit is respected? Because as it stands, the validator for tags in Item only checks the number of references stored, not the amount of tags assigned to an item. Am I wrong?
Ideally, the controller for adding items should be able to process such requests in a single operation:
async function addItem(req, res) {
try {
let item = await Item.create(req.body);
res.status(201).json(item);
} catch (err) {
res.status(400).json({ response: err.message });
}
}
Or am I going to have to first add tags and do something like item.tags.push(tags) afterwards?
I am trying to implement a custom normalizer to the configurable product feature module. I have to include a custom field in the Attributes datatype. Currently only the OccConfigurationVariantNormalizer is available, which is quite high level form a data's point of view.
My problem occurs with the execution order of the normalizers. The default normalizer ist this: https://github.com/SAP/spartacus/blob/develop/feature-libs/product-configurator/rulebased/occ/variant/converters/occ-configurator-variant-normalizer.ts which is being called after my custom normalizer. Hence, the convertGroup() function is overriding my custom attribute field.
Here is my implementation:
#Injectable({
providedIn: 'root'
})
export class CustomConfiguratorNormalizerService extends OccConfiguratorVariantNormalizer{
convertAttribute(sourceAttribute: CustomOccAttribute, attributeList: CustomAttribute[]): void{
super.convertAttribute(sourceAttribute, attributeList);
attributeList[attributeList.length - 1].customField = sourceAttribute.customField;
}
}
Extending the original Normalizer seemed like the most promising solution for the time being, and is working quite like intended. So the customField ist being present at this point in time of execution.
Afterwards the OccConfiguratorVariantNormalizer kicks in, which is defining a new Attribute array in convertGroup(), erasing my custom attribute:
convertGroup([...]) {
const attributes: Configurator.Attribute[] = [];
if (source.attributes) {
source.attributes.forEach((sourceAttribute) =>
this.convertAttribute(sourceAttribute, attributes)
);
}
[...]
};
convertAttribute(
sourceAttribute: OccConfigurator.Attribute,
attributeList: Configurator.Attribute[]
): void {
const attribute: Configurator.Attribute = {
name: sourceAttribute.name,
label: sourceAttribute.langDepName,
required: sourceAttribute.required,
uiType: this.convertAttributeType(sourceAttribute.type),
values: [],
groupId: this.getGroupId(sourceAttribute.key, sourceAttribute.name),
userInput: sourceAttribute.formattedValue,
maxlength:
sourceAttribute.maxlength + (sourceAttribute.negativeAllowed ? 1 : 0),
numDecimalPlaces: sourceAttribute.numberScale,
negativeAllowed: sourceAttribute.negativeAllowed,
numTotalLength: sourceAttribute.typeLength,
selectedSingleValue: null,
images: [],
hasConflicts: sourceAttribute?.conflicts?.length > 0 ? true : false,
};
[...]
};
If my custom normalizer was the only one I could imagine it would work, which is why I tried to inject it like this:
{
provide: VARIANT_CONFIGURATOR_NORMALIZER,
useClass: CustomConfiguratorNormalizerService,
multi: false,
}
Throwing me Error: Multi-providers mixed with single providers.
Also, using the documentation from https://sap.github.io/spartacus-docs/connecting-to-other-systems/ I cannot get it to work without extending the original Normalizer, since target will always be undefined, which probably would not be the case if my custom normalizer came in second.
I feel like this https://github.com/SAP/spartacus/issues/9046 could be related.
Any help very much appreciated :)
I was able to solve this myself. Following the reference structure for spartacus applications at https://sap.github.io/spartacus-docs/reference-app-structure/ the problem disappeared.
My best guess is that it has to do with the import order of the modules. In my current working version I import the FeaturesModule last, which seems to solve the problem.
I'm attempting to set data fields provided by an array based on the Vue Router query. For example, when someone lands on my website using example.com/?location=texas, I want to set the location data by an array.
An example the array:
locations {
{
slug: "texas",
tagline: "Welcome to Texas",
}, {
slug: "california",
tagline: "Welcome to California",
}
}
I know this should be done using a computed property, however I am unable to get anything functioning. I've tried simple tests like if (this.slug.location === "texas"), and I cannot get the location data to populate. I would also like to provide default data in case there are no route matches.
Any help is extremely appreciated!
Edit:
I can accomplish this in a very manual way. Right now, I'm setting the query in data by the following:
slug: this.$route.query.location
I can display specific text by doing something like:
h3(v-if="slug === 'texas'") This will show for texas
h3(v-else-if="slug === 'california'") This will show for California
h3(v-else) This is default
The issue with this approach is there are various elements I need to customize depending on the slug. Is there any way I can create an array, and move whichever array matches a key in an array to the data??
You should be able to access a query param using the following (link to Vue Router documentation):
this.$route.query.location
So based on what you listed I would do something like...
export default {
computed: {
displayBasedOnLocationQueryParam() {
switch(this.$route.query.location) {
case 'texas':
return 'Welcome to Texas'
default:
return 'hello there, generic person'
}
}
}
}
Note that I'm not using your array explicitly there. The switch statement can be the sole source of that logic, if need be.
I have a React Native App that gives me a list of properties. Each property has it's own page and a link to a screen that lists all the notes that are associated with that property AND that user. So, a user can only see the notes that they have created for this specific property on this screen.
I'm having trouble writing a GraphQL query that gets all notes associated with the current property AND the current user.
My basic instinct is to write it like this...
const getNotes = gql`
query getNotes {
allPropertyNotes(filter: {
AND: [{
propertyId: ${this.props.navigation.state.params.id}
}, {
userId: ${this.props.screenProps.user.id}
}]
}, orderBy: createdAt_DESC) {
id
title
body
}
}
`;
But this doesn't seem to work because the query is defined outside of the component and doesn't have access to this.props (I'm assuming).
My next though was to do it like this
const getNotes = gql`
query getNotes($userId: ID!, $propertyId: ID!) {
allPropertyNotes(filter: {
AND: [{
propertyId: $propertyId
}, {
userId: $userId
}]
}, orderBy: createdAt_DESC) {
id
title
body
}
}
`;
But I'm not sure how to bind the variables to the ID's that I need them to be. Any pointers on how to do this?
If you need only 'query on mount' then just render <Query/> component using props as variables. Example with variables
The same you can do with graphql() options.variables
Passing query (fired at start by default) and [many] mutations as props are for more complex cases. docs
Docs are not verbose here, you have to gather knowledge from many places/pieces or search for tutorials.
I have several questions about Apostrophe CMS:
Is it possible to add a unique field type in apostrophe-pieces? I can't find a way to do this.
Edit: I noticed that I wasn't specific enough. I want to make sure that there can't be two instances in the database with the same value in an added field. It should be something like an additional id. Is there an option for this? Maybe something like:
addFields: [
{
name: 'secondId',
label: 'Second ID',
type: 'string',
required: true,
unique: true
}
]
I want to access the apostrophe-headless api and get a specific element by passing a certain value of one of the created field types of the correspondent piece in a GET-parameter. Is something like this possible?
For example:
Piece:
module.exports = {
extend: 'apostrophe-pieces',
name: 'article',
label: 'Article',
pluralLabel: 'Articles',
restApi: {
safeFor: 'manage'
},
addFields: [
{
name: 'title',
label: 'Name',
type: 'string',
required: true
},
{
name: 'author',
label: 'Author',
type: 'string',
required: true
}
]
};
Desired api call for getting all articles which have strored "Jon" as author:
http://example.com/api/v1/article?author=Jon
Thank you very much in advance!
Custom field types
You can add custom field types at project level by extending apostrophe-schemas and adding the proper definition. You'll need to add a converter for server-side sanitization and a populator for the front-end of the form field.
You can follow the examples in Apostrophe's schema module, linked are the functions defining a float
https://github.com/apostrophecms/apostrophe/blob/0bcd5faf84bc7b05c51de7331b17f5929794f524/lib/modules/apostrophe-schemas/index.js#L1367
https://github.com/apostrophecms/apostrophe/blob/0bcd5faf84bc7b05c51de7331b17f5929794f524/lib/modules/apostrophe-schemas/public/js/user.js#L991
You would add your definitions in your project level lib/modules/apostrophe-schemas's index.js and public/js/user.js respectively.
Filtering
You can search your piece index for a string like Jon by adding ?search=jon to your query but more likely you want to filter pieces by the value of a join.
If you had piece types article and authors, you could have a joinByOne field in article's schema that lets you relate that article to an author piece. Then, by enabling pieceFilters you could filter directly on those joined properties.
A complete rundown of piecesFilters can be found here https://apostrophecms.org/docs/tutorials/intermediate/cursors.html#filtering-joins-browsing-profiles-by-market
I think you'd also need to mark that filter as safe for api use in your apostrophe-headless configuration https://github.com/apostrophecms/apostrophe-headless#filtering-products