fix: handle multi-type schemas in node type inference

[itvi-1234]

Summary

This PR fixes an issue where multi-type schemas (e.g., ["string", "null"] or ["integer", "number"]) were failing type inference. Previously, the logic only accounted for primitive string types, causing multi-type nodes to fall through and render with the default "others" (gray) styling.

What Changed

• src/utils/inferSchemaType.ts: Updated the type inference logic to properly check if the type property is an array. When an array of types is encountered, it selects the first non-null type as the primaryType (e.g., extracting "integer" from ["integer", "null"]). This ensures the node receives the correct semantic coloring based on its primary data type.

##Closes #339

Testing

Test with the following schema to verify the nodes render with their correct semantic colors and display the array values properly:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": ["integer", "null"] },
    "score": { "type": ["number", "string", "null"] }
  }
}

• age should render with neon mint coloring (for integer).
• score should render with neon mint coloring (for number).

[github-actions]

Preview Deployed!

Item	Status
Latest Deploy	Visit Preview
Environment	Preview (PR-347)
Action	View Logs

Last updated at 2026-06-30T06:31:36Z

[itvi-1234]

hi @AgniveshChaubey , @jagpreetrahi , Please review the PR whenever have some time , I have tried and tested it with many schemas , Lemme know if any changes required 🚀

[jagpreetrahi]

Hey Sumit , I've suggest some changes you can have a look into it.

[jagpreetrahi]

Hey sumit,
I would like to suggest one thing as instead of using .find() function for getting a primary Type, can we use the for..of loop. The reason to say it because .find() function must look at every elements sequentially until it find a match and that gives O(n) time complexity in worst case scenario. So, for that concern I looked for alternative one to replaced it.
What I was thinking as we can used for..of loop that optimizes the hidden performance cost called as constant factor that .find()suffer from it.

By doing this we have following advantages as - No callback function overhead : for .find() - JS engine execute its callback for every single element in an array , but in loop, there are no function being constantly called.

Immediate memory allocation : while .find() runs , a new arrow function closure is allocated in the memory, loop allocates exactly zero functions. It has no memory allocation footprint.

However, both these approaches takes O(n) in the worst case, but loop approaches will save us from above mentioned points.

Thanks

[jagpreetrahi]

Happy to hear out what do you think on this? Agnivesh.

[jagpreetrahi]

Hey @sumit, have you explored about a suggestion?? ,

[itvi-1234]

Hey @jagpreetrahi , I didn't get notified that you have reviewd the PR . Am sorry for that , Now , I have the full context

[itvi-1234]

and looking for the suggestions to improve complexity

[itvi-1234]

Hi @jagpreetrahi, thank you for the detailed explanation and for pointing this out! 😊

I wanted to share a thought — in this specific case, the type array in a JSON Schema will always be quite small (typically 1–2 elements, e.g., ["string", "null"]). Given that constraint, the O(n) complexity and the callback overhead of .find() would be practically negligible here.

However, I completely understand the value of consistency and avoiding even micro-overhead as a habit. I'm happy to go ahead with the for...of approach if you'd prefer it — just let me know and I'll update it! 🙌

[jagpreetrahi]

Yeah, I agreed on that about the size of an array as slightly small in the context of JSON Schema.
So I think we need to see what Agnivesh think about it and will move on.

[itvi-1234]

Hi @AgniveshChaubey , Could you please provide some directions regarding it

[itvi-1234]

Hi @AgniveshChaubey and @jagpreetrahi , could you please review this PR whenever have some time

[AgniveshChaubey]

The type element's color looks too punchy... I think we should make it a bit light (maybe making it transparent would work).

Also, in light mode, text is not quite readable.

[itvi-1234]

Hi @AgniveshChaubey & @jagpreetrahi ,I have made the background a bit light , could you please review this PR whenever have some time