Using functional components in non-html output types

[kristiandavid]

We're using class components for non-html output type components but were told we could use functional components instead. How would we go about using content sources in non-html functional components? We can't use useContent, but wondering what other ways we could use our content sources.

What we were told when asked about it earlier this year:

Regarding the functional components vs Class components - that should be fully supported. If you run into issues, you might have been returning an incompatible content type from the functional component.
Some code snippets in the documentation have not been updated, but functional components are as supported in non-HTML as they are in HTML outputTypes.

[radominchev]

Hello @kristiandavid and Happy New Year!

Thanks for the question. The Arc XP guide on building non-HTML APIs lays out the recommended pattern for pure JSON endpoints:

• Implement a dedicated json output type (contentType: application/json) that returns the first child payload.
• Use a JSON layout (recommended/required due to a known children-structure issue) that returns the body payload.
• Use content sources for data access (e.g., story/section queries), then a feature that fetches those sources and composes the final JSON shape (returning plain objects/arrays—no JSX).
• If the API response is an array, use a chain to aggregate feature payloads into an array response.
• For PageBuilder Admin usability, add corresponding “default” (HTML) versions of the same components to provide a readable visual preview, while downstream consumers call the endpoint with outputType=json.

Could you review that pattern and let us know which maps to your use case:

1. a single-object payload (one feature returns one object), or
2. an array payload (a chain returns an array of objects)?

Best, Rado

[jpblancoder]

@radominchev The guide's example has a React Class component (with this.fetchContent method) for the "Creating a feature to combine section data and stories" section. Which we've used to implement some JSON output-type pages successfully.

We want to know if you can provide a code example for a React Functional component (with useContent hook), that can combine section data and stories in a similar way. If that's even possible.

That would make it easier for use to share React hooks, that may wrap useContent, between "default" (HTML) and JSON output-type feature/block Functional components. Thanks.

[jpblancoder]

@radominchev Hi, could you escalate this question with your team? Thanks.

[radominchev]

Hey @jpblancoder, thanks for your follow up! I found this idea where you asked about the feature and it appears that it is yet to be prioritized.

Best, Rado

[kristiandavid]

@radominchev is there any other way that we can call our content sources in functional components that return json? I understand useContent doesn't seem like a possibility at the moment but we've heard it is possible to call content sources in functional components for this purpose. If not, let us know and we'll stand by in the hopes of seeing tis functionality one day. Thanks.

[mfyz]

Hey all, chiming in here, JP commented on the feature request idea, I'm copying my response there:
useContent relies on React Context internally when it is bundled via Webpack. It calls useContext(Fusion.contexts.app) to get the content fetching machinery. That context only exists when the JSX engine renders a full React tree. JSON output types run as plain JS functions, no React tree, so hooks have nothing to pull from.

But this isn't a functional gap. The JS engine passes context through props directly, and the Consumer HOC exposes it as this.getContent() (documented here). Same capability, different API:

import Consumer from 'fusion:consumer';

class MyJsonOutputType extends Consumer(React.Component) {
  render() {
    const { cached } = this.getContent({ source: 'my-content-source', query: { id: this.props.id }, });
    return JSON.stringify({ data: cached });
  }
}

export default MyJsonOutputType;

The limitation is ergonomics. I agree, class components feel dated compared to hooks.