Building a custom component with vueFlow (nodes)

So I wanted to use nodes for some projects, something like reactFlow

I was intimidated by weweb’s coded components creation, but then I tried giving it a go

This video basically did the job for the “learning” part: https://youtu.be/fkH56RGEUTc

Honestly, I am glad to see that, with this video, the documentation, cursor and a little bit of programing knowledge (I do not know how to really code, but I know how the stuff works under the hood), I am being able to create what I want!

Gravando 2025-05-21 093459

There is still a bunch of stuff that I need to implement, but I am feeling very confident I can do it :slight_smile:

11 Likes

Azuliani, this is Amazing!

Congratulations :tada:

Reminds me of the nodes in game development like Blender or Unreal.

Can’t wait to see what you come up with next!

Morgan Freeman Applause GIF by The Academy Awards

That’s a really nice one!

1 Like

Christian Bale GIF by PeacockTV

Well done!

WeWeb should make an MCP server (they can do this in Xano :slight_smile: ) specifically for wrapping a Vue component into a WeWeb component. Would not be a huge lift actually - then anyone in Cursor or Windsurf could vibe to a Vue component - and them prompt to a “WeWe component”. :wink:

I think it’s great that WeWeb is doing native AI .. .but I am sorry … they will never compete with Cursor and Windsurf and others in this regard for more advanced stuff.

1 Like

What if we provided a cursor like experience for building weweb component, directly inside WeWeb ?
We added recently a component editor so everyone can directly edit the code of their components and even fork (duplicate) them.

I’m thinking of pushing it further by allowing WeWeb AI to edit the code inside the component editor, instead of generating/updating the component instantly.

Would it make WeWeb AI a better choice to help you build custom coded component ?

Why waste time on this? It would probably be much more simpler and economical to let the Cursors and Windsurfs be best at what it’s best and only facilitate their integration within WeWeb. On one side I understand your point, which would’ve make sense, if you guys were focused on a code editor. But you’re a no-code tool, and there is plenty of people doing AI (as their main focus) better, so I’d try to look for synergies, rather than making WeWeb do everything and eventually nothing.

4 Likes

By the way, this is a really cool post! I highly encourage you trying out adding dropzones into the nodes! Or making the nodes actual dropzones! That would be very cool, I can see that being a thing in WeWeb where people would buy this in the Marketplace even.

2 Likes

:folded_hands::folded_hands::folded_hands::folded_hands: - unless you do a VC round and scale your core dev team by at least 2X if not 3X.

Focus your AI efforts on ONLY working with Figma & core components. Integrate via MCP for custom components in Windsurf, Cursor, etc

I’m asking because for me it would be worth if it can allow more people feeling confortable building this kind of component without requiring additional tools or specific technical knowledge.

Of course it depends of how much work it would take to fill this gap, that’s why I’m reaching out for feedbacks and understand the limitations our builders are encountering.

The best choice could be to build an MCP as suggested or simply share custom prompts to help everyone build weweb components in their favorite coding tools, I agree.

3 Likes

The thing is - code editors are becoming more and more non-code friendly. So … barrier for WeWeb users to use Windsurf, Cursor etc is lower every day - and when user tries to do this in WeWeb AI … and they get a poor result … it’s worse for WeWeb than not having the functionality at all.

Even if you disagree with me - you are CRAZY not to release an MCP focused on this. As you know - not a huge lift - (you make a tool laser focused on wrapping the VUE w/parameters etc)- especially if you do it in Xano.

Sharing prompts is helpful for people learning who have less vibe coding experience as a very general reference- but definitely NOT a “solution”.

2 Likes

All about focus. If WeWeb would have gone full stack - like Bubble - with backend - do you really think for one split second WeWeb would be as good as it is today? Supabase & Xano both have meaningful teams and funding - the fact that WeWeb users can use either is a huge win. Cursor & Windsurf, etc have significant teams and funding focused prompt to code - and YES you can do it - just like you COULD go full stack … but why not just be the absolute most joyful and awesome nocode front end editor ??

And of course you should do as much with AI assist inside WeWeb as you can without impacting bug fixes etc - but for custom components… not the hill you should die on. It will never be as good as using Cursor, Windsurf etc. That’s a reality.

3 Likes

Same opinion here, by each day passing that the vibe coding tools became more non-code friendly, the decision to move from Weweb to full code front-end is getting thrown a lot more often in our meetings than few years ago because Weweb AI is slowing us down VS our full code projects from Cursor/Windsurf/Cline that now has a better velocity than Weweb.

I agree with everyone: focus on what weweb is good for…

Seriously, I DO NOT KNOW HOW TO PROGRAM. I know very little, and I was able to find my way around building a coded component. With stuff like Cursor, I really don’t think we’d need too much stuff in weweb to develop these things.

I think a slightly better documentation (specially with a step by step guide to get going) would be all I ask for. And only if this do not interfere with development/improvement of the core product.

100%. This conversation is happening at EVERY SINGLE NO-CODE AGENCY right now. Daily.

And WeWeb can STILL hold their ground and GROW because there IS still a HUGE advantage to a visual nocode editor vs prompt to code.

But … WeWeb needs to focus on velocity for users.

Show stopping bug fixes can’t take 5 days +

NO BREAKING CHANGES EVER. Changes to core components need to be versioned and NOT auto updated into a build that already used the prior version of the component.

WeWeb can win - if the focus is on what they do BEST - and … double down on key integrations.

KEEP making Supabase integration more dynamic.
KEEP making XANO integration more dynamic.
Make custom components FAST and EASY via MCP to Cursor & Windsurf, etc

Focus AI efforts on → updating and iterating on core components + FIGMA to 1st draft build w/core components. THIS is actually what your users want.

There is also no long term future without branching and SSR IMO. Those two missing things will more and more pull users away.

Velocity for users … ability to iterate quickly. No breaking changes. THIS is the hill to die on.

2 Likes

To add even more to this topic, since the last AI update (this week), the AI isn’t able to do ANYTHING at all on our bigger projects… (probably too much context from the project since the page only has an empty section)

To Weweb team: PLEASE MAKE IT EASIER TO USE BEST IN CLASS TOOLS (MCP/Cursor/Windsurf/etc…) instead of trying to build everything in-house and always being late (Like the AI update to Claude Sonnet 3.7 the day after Anthropic release an even better model) VS a dedicated team focused on a narrow problem (like Cursor/else…)

This post will be closed as the conversation has moved away from the original intent :wink:

If you’d like to continue the discussion or share feedback, feel free to start a new thread, that way we can keep each topic focused and make space for more constructive conversations. Thanks everyone for understanding! :folded_hands:

Edit: @dorilama started a new conversation about those issues, feel free to comment there:

3 Likes