Props argument in default argument of a prop

[Starlord48]

props: {
prop: {
type: String,
default: function(props:Record<string, any>){}
}
}

what is the reason we have the props as an argument in default. We tried to replace the defaults of the props using another prop.

So the use case goes like this, we have a prop that determine the type of a chart and we have prop map of each type. So the type prop is used to determine the default value of the other props. So we tried to utilise the props argument in the default function to access the type prop and setting the default of the other props.

function getDefaultProp(props:Record<string, any>,name:string,defaultValue?:any):any {
let displayType = props.displayType;

let config = propMap[displayType];
if(config && config.props && name in config.props){
    defaultValue = config.props[name];
}
if(isFunction(defaultValue)){
    return defaultValue(props);
}

return defaultValue;

}

export const props = {
displayType: { type: String, required: true },
.
.
.
}

for(let name in props) {
let value = props[name];
const def = extend({},value);
def.default =()=>undefined;
propsWithoutDefault[name] = def;
if(name ==="displayType"){
continue;
}
if (!value || !value.type) {
Logger.fatal(Prop '${name}' type is not defined inside object. for flo chart it is mandatory to define the prop as <prop_name> : { type : <String|Number| etc>}. );
continue;
}

let defaultValue = value.default;
value.default=function(props:Record<string, any>){
    return getDefaultProp(props,name,defaultValue)
}

}

[YitzhakMizrahi]

The props argument exists so a default factory can look at the raw props that were passed into the component.

That means your use case is valid in principle: a default for one prop can be derived from another prop such as displayType.

The important caveat is that this argument is the raw props object, not the fully resolved props object. So it is useful for checking values the parent actually passed, but you should not rely on other props already having their own defaults applied.

A smaller version of the pattern would be:

props: {
  displayType: {
    type: String,
    required: true,
  },
  chartConfig: {
    type: Object,
    default(rawProps: Record<string, unknown>) {
      const displayType = rawProps.displayType as string | undefined
      return displayType && propMap[displayType]
        ? propMap[displayType].chartConfig
        : {}
    },
  },
}

So the reason Vue passes props is exactly to replace the old Vue 2 pattern of reading this inside default functions. In Vue 3, default factories do not have component instance access, because props are resolved before the component instance exists.

For your generated/default-wrapping approach, I would keep two rules:

• Only depend on props that are required or explicitly passed by the parent, like displayType.
• Do not depend on another prop default having already run, because defaults are not meant to be an ordered dependency graph.

Docs: https://vuejs.org/guide/components/props.html#prop-validation

[GitNimay]

The props argument in a prop default function is the raw props object passed to the component. It exists because, in Vue 3, default functions no longer have access to this, so Vue passes the raw incoming props instead.

So this is valid:

someProp: {
  type: String,
  default(rawProps) {
    return rawProps.displayType === "bar" ? "bar-default" : "default";
  },
}

But there is an important limitation: these are raw incoming props, before Vue finishes resolving defaults and type casting. That means this pattern is OK for reading a required prop like displayType, but it is not a good place to build a complex dependency chain between defaults.

For your specific use case, I would avoid dynamically rewriting every prop’s default function. It can become hard to reason about, and it only works when the prop is absent or explicitly undefined. If the parent passes the prop, Vue will not merge it with the default.

A safer pattern is to keep the external props simple, then derive the effective chart config in a computed value:

const props = defineProps({
  displayType: {
    type: String,
    required: true,
  },
  title: String,
  width: Number,
  options: Object,
});

const effectiveProps = computed(() => {
  const defaults = propMap[props.displayType]?.props ?? {};

  return {
    ...defaults,
    title: props.title ?? defaults.title,
    width: props.width ?? defaults.width,
    options: {
      ...defaults.options,
      ...props.options,
    },
  };
});

Then use effectiveProps.value internally to render the chart.

This keeps Vue’s prop system responsible only for validation and input, and keeps your chart type based defaults in normal application logic. It also handles partial object overrides better, because Vue prop defaults do not deep merge objects.

So the short answer is: the argument exists so a default factory can look at raw incoming props, but I would only use it for simple defaults. For chart type specific defaults, use a computed “resolved config” layer instead.

[aymenhmaidiwastaken]

The props argument in a default factory exists because Vue 3 removed this access in default functions (unlike Vue 2). So Vue passes the raw incoming props instead, letting you derive one prop's default from another.

Your use case is valid — deriving defaults from displayType — but there's a key limitation: the props argument contains raw incoming props, not fully resolved ones. Other props' defaults may not have run yet. So only depend on props that are required or explicitly passed by the parent.

For your chart config pattern, I'd recommend using a computed instead of rewriting default functions dynamically:

const props = defineProps({
  displayType: { type: String, required: true },
  title: String,
  width: Number,
  // ... other props without complex defaults
});

const resolvedConfig = computed(() => {
  const defaults = propMap[props.displayType]?.props ?? {};
  return {
    title: props.title ?? defaults.title,
    width: props.width ?? defaults.width,
    // ... merge each prop with its type-specific default
  };
});

Then use resolvedConfig internally instead of reading props directly.

Why this is better:

• No fragile dependency on prop resolution order
• Handles partial overrides cleanly
• Reactive — if displayType changes, defaults recalculate
• Vue's prop defaults don't deep-merge objects, but a computed can

The props argument in default functions is fine for simple cases (e.g., one prop depending on one required prop), but for a full config-map pattern like yours, a computed layer is more robust.