Hi, I just finished a demo project to test weweb.
The demo uses weweb auth, airtable and a custom plugin that integrates Stripe Elements.
Here is a link to the video of the demo.
Integrating custom code with weweb was really nice. Here is the link of the integration on github.
This is so cool! Thanks for sharing @dorilama
That’s so cool
Well done to have built this!
Thank you both for the kind words
congratulation to your first element !
I have a bunch of feedbacks, lot of thinks which are not documentated on our side, so not your fault at all ! It’s just pointing me thinks which need to be documentated as best practises, and that we learned by developping a lot of them !
- I am not sure, but do you use that as a section or an element?
- ww-config.js and content should only contains properties which need to be edited or initialized inside editor, and saved in Weweb database. Here
error are more state of your component than parameters. You should probably move them to data of your Vue component and delete them from the configuration file, as they do not need to be saved in Weweb server (not sure if i am clear or not?)
- If you plan to make it more reusable, I strongly advice you to let Weweb handle some css stuff such as width, radius and padding. So delete the css of your container, and let it be define by Weweb properties. It will probably look less cool when dropped from the source code, but then you can add cool base settings for that, and save it to your design system.
- For the same reason, it’s better to have one root dom element
- You can use other Weweb element inside your own so its more customizable. For example your button can be a wwElement of type ‘ww-button’ and then people can change easily color, padding , text etc
- Same stuff for the error text
- You can stripe code which are only used inside the Editor. This is better for performance (editMode for example does not exist in the published website, and some watcher are not mandatory)
- It is advanced usage, but you can add an editorOnly toggle to forced the display of error for a better editing experience :).
- Be sure that the clientSecret is handled correctly for security (not saved inside the editor, only provided as a variable from a request)
I am very happy and impressed by the fact that you manage to have element variable and custom event working !
If you want to talk about it an a video call, feel free to contact me, I will be happy to provide a more interactive and deep feedback about how to develop a Weweb element. It is very valuable for us to have feeback from external user on developing component.
thank you very much for your feedback, I appreciate it a lot.
TLDR: I am aware of some of the problems you mention. This first prototype was just a mix of the stripe doc with the weweb docs (es. the styles are the same as the stripe tutorial on elements) and the main goal is to get my feets wet with weweb, both editor and plugins.
Quick questions (more details in the long answer after this):
- how do you expose values to the app if not with properties? It seems I can’t find the payload of the triggered events in the editor.
- is there a better way than
wwEditorState.editMode to detect edit mode to show a placeholder or disable buttons/other methods when in edit mode?
- is there a way to detect dev mode (both editor and preview) to handle the switch of api key from test to live?
- is there a way to set default values for wwElements (es. a default background color for a ww-button I add inside the plugin)
Now the long version:
I was not sure as well . Now I think it should be an element without any style for the container
You are clear. The idea is that I want to notify the app about
error so I can show toast notification ecc. (es. try to pay with a declined card in the demo).
stripeLoaded is not used in the demo but the idea is that because stripejs is loaded asynchronously you may need to know if it did not load correctly when the error occurs so that you can reload the page, but I am not convinced this is the best way of doing it.
So the idea was to have a variable exposed to the app and read it when the event is triggered.
Of course it make more sense to pass the error as a paylod of the event but then I don’t see the payload in the editor when setting up the workflow.
So I checked the input element on github and for what I understand you are using
setValue of the property
value. I tried to use that and it works but it does not smell good that I have to hide the property from the editor.
I guess I am missing something regarding the event payload. What is the best way to expose values to the app?
You are right. I am planning on removing the styles on the container and add the other properties that Stripe accepts for Elements.
ops! My bad
that is very useful, I didn’t know about it. Do you mean something like this in the ww-input-search? I am trying it now. It seems easier this way. Is there a way to set default values for some style (es. background color)?
of course. This should actually be a wwElement and there should be an option to disable it if you want to display the messages in the app in other ways.
I know but I am using
wwEditorState.editMode to disable buttons when in edit mode, otherwise they trigger click methods when you select/click te element. This was happening for my button but from a quick test it seems it happens also if I use a wwElement of type
ww-button as you suggested. Also you may want to show a different placeholder when in the editor (Stripe Elements are dynamic and you don’t control them so a placeholder seems better in edit mode), or you do not want to trigger some functions when in edit mode (load stripejs on mount but only if it is the preview)
Is there a better way to detect edit mode and disable some functions?
Also is there a way to detect if the plugin is used in development or test in order to handle the switch between test and live keys?
I am not shure I get this. Are you referring to this https://developer.weweb.io/api/#property-editoronly? In my case the idea of
editor property is to read it from the app and display it in any way you want.
clientSecret is not a secret key and is indeed provided as a variable from an API request and it is used by stripejs to setup elements (doc: Stripe API reference – The PaymentIntent object – curl and Accept a payment | Stripe Documentation). The api calls that require the stripe secret key for this demo are handled by a function on cloudflare workers that forwards requests to stripe using only the test key. It seems a flexible way to test stripe integrations. I understand that the api requests made from weweb with the “Make this request through a server” switched on expose all the parameters to the frontend anyway. Am I correct?
Thank you again for your feedback.
I think I didn’t reply directly to this post. Sorry about that . See the previous post for my reply
I just finished a new version of the Stripe Element integration with support for appearance customization.
Thanks to @aurelie for the help.
It is open source, you can fork the repo and import the element in your weweb dashboard.
You can find the repo on github.
This is stupendious!! Thank you Dorilama!
Thanks for the kind words Kevin