In our project, we realised we cannot use <cx-icon> in our templates if strictTemplates is set to true without using $any(...), from Angular, as a workaround.
We have our own list of CUSTOM_ICON_TYPE's, so after we set strictTemplates to true, Angular complained about our own icon types. This code:
<cx-icon [type]="customIconTypes.CHEVRON_RIGHT"></cx-icon>
gives this error:
Type 'CUSTOM_ICON_TYPE.CHEVRON_RIGHT' is not assignable to type 'ICON_TYPE'. ngtsc(2322)
Here is an example of our current workaround:
<cx-icon [type]="$any(customIconTypes.CHEVRON_RIGHT)"></cx-icon>
Is there any other known workaround for that? Or is an update on cx-icon already planned in the future?
According to the docs the configuration of the icons was designed to be provided for in a different way.
Please try this:
ConfigModule.withConfig(<IconConfig>{
icon: {
symbols: {
CHEVRON_RIGHT: "<value of customIconTypes.CHEVRON_RIGHT>",
},
},
});
Related
currently working on an issue and cant figure out why my page throws me an error.
Having this component:
<JobDetailSectionText
:variant="tmpl({ red: 1, blue: 4, yellow: 7 })"
:image-src="
jobProfile.attributes.imagePractice
? $strapi.options.url +
jobProfile.attributes.imagePractice.data.attributes.url
: '/static/img/praxisteil.jpg'
"
:image-alt="
jobProfile.attributes.imagePractice.data.attributes.alternativeText
"
>
In my content manager in Strapi I changed the „attribute.imagePractice" from required = true to false and now want to, if no file is added to the database show a default image in '/static/img/praxis.jpg‘.
But the console of the page gives me an error
"TypeError: Cannot read properties of null (reading 'attributes')
I tried to figure out the source of the problem but the page only works if I add and imagePractice in the backend, it won’t take the default img I tried to declare with the static path.
Any thoughts?
Thanks!
You can use optional chaining to check if property is exist
<JobDetailSectionText
...
jobProfile.attributes?.imagePractice
? $strapi.options.url +
jobProfile.attributes.imagePractice.data.attributes.url
: '/static/img/praxisteil.jpg'
"
...
>
#DinhTX solution is good, but note, that you cannot use optional chaining unless it's Vue 3. Read more here.
If you're using Vue version less then 3 you would need to write a computed property for that src attribute value where you'd check if attributes exist. Actually, I'd recommend you to use computed property anyway cause Vue's templates should be more HTML and less JS (not like React).
Example of computed property would be:
computed: {
jobSrc() {
const strapiUrl = `${$strapi.options.url}${jobProfile.attributes.imagePractice.data.attributes.url}`
return jobProfile.attributes?.imagePractice ? strapiUrl :'/static/img/praxisteil.jpg'
}
}
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.
On setting colors from configuration and using Gooddata UI Charts component it is throwing following error
TypeError: item.predicate is not a function
My config is as follows, On reseting default color it is working fine but as change color i get the colorMapping object in the api and after applying this config throwing the error.
How can i resolve it, Please help me out.
config={{
colorMapping: [{
color: { type: "guid", value: "17" },
id:"0d447449c2844b228923c37de7b6aaf9"
}]
}}
usage of ColorMapping is described in documentation
https://sdk.gooddata.com/gooddata-ui/docs/chart_config.html#Color-mapping
You need to define predicate function which when returning true, will apply corresponding color (https://sdk.gooddata.com/gooddata-ui/docs/ht_create_predicates.html).
In your case localId predicate seems to be right for you
https://github.com/gooddata/gooddata-ui-sdk/blob/master/libs/sdk-ui/src/base/headerMatching/HeaderPredicateFactory.ts#L264
In case you are using older version of Gooddata UI.SDK than v8, you need to implement predicate by your own. Something like this (or equivalent for measures).
predicate: headerItem =>
headerItem.attributeHeaderItem &&
headerItem.attributeHeaderItem.localIdentifier === "0d447449c2844b228923c37de7b6aaf9", // find attribute item by localIdentifier
You can switch the official documentation to whathever version of Gooddata UI.SDK lib you are using and read the same article about ColorMapping
https://sdk.gooddata.com/gooddata-ui/docs/7.9.0/chart_config.html#color-mapping
I have been trying to use a rallyaddnew to add Features and Rollups, which will then be rendered in a grid/cardboard. I got it to work and display, but I cannot customize the text to say create a new "Feature" or "Rollup", rather it says create a new "PortfolioItem/Feature" and "PortfolioItem/Rollup"
{
xtype: 'rallyaddnew',
recordTypes: ['PortfolioItem/Feature', 'PortfolioItem/Rollup'],
listeners: {
recordAdd: function() {
//
},
beforeRecordAdd: function() {
//
}
}
I couldn't find anything in the SDK on how to customize this.
This is a defect. It should be using the display name of the type instead of its type path. I'll file a defect for this. FYI there is also an existing defect around PI types and adding with details that has been fixed but has not been released in an SDK version yet.
Within Sencha Touch, is it possible to define a default UI , like "light" or "dark", that applies to all components (unless overwritten explicitly)?
The aim is to avoid having to declare ui: "dark", or any custom UI that is made, for every element.
Cheers!
You can try this:
Ext.apply(Ext.Component.prototype, {
getUi: function() {
var defaultUi = 'light';
// value of [this.config.ui] is ignored here
// we can use something like forcedUi
return (this.forcedUi) ? this.forcedUi : defaultUi;
}
})
The disadvantage of this code is that we need to specify another variable for applying ui different from 'light' (because variable 'ui' via getUi() will always return 'light'):
...
items: [{
xtype: 'button',
forcedUi: 'dark'
}]
...
I am stuck on Touch 1.1 so sunsay's solution didn't work for me, but this did:
Ext.CustomToolbar = Ext.extend(Ext.Toolbar,
{
ui:'app'
});
Ext.reg('toolbar', Ext.CustomToolbar);
So, it's still component-by-component-type, but not component-by-component-instance. And since you can overwrite the "reg", no need for custom x-types all over the place, either.
I assume that you know about sencha touch styles and themes. Otherwise you can download a pdf file from this link which clearly describes about how to do it...
http://f.cl.ly/items/d9df79f57b67e6e876c6/SenchaTouchThemes.pdf
In it they are mentioning about scss file where you can specify the base-color, ie
$base-color: #4bb8f0 ;
$base-gradient: 'glossy';
Then run it ... you can see the toolbars and buttons created with the color and gradient you have mentioned.