Finland
Account created on 20 December 2010, over 14 years ago
  • Principal Software Engineer in the Drupal Acceleration Team at Acquia 
#

Merge Requests

More

Recent comments

🇫🇮Finland lauriii Finland

Also, what would happen if user provided a prompt "Make the header sticky so it stays at the top on scroll"? This seems like a common use case which we should think through. Usually you'd probably have some kind of header component which the AI probably should modify in this scenario. Alternatively if the header is an SDC, it could create a new component that wraps the existing component to add the sticky header behavior.

🇫🇮Finland lauriii Finland

Have we considered refinements to the header and footer here at all? For example, "I'd like to add a 'Start free trial" button in the header that links to #" or "I'd like to add a 'Contact' link that links to '/contact' to the header".

🇫🇮Finland lauriii Finland

This is inline with what we have discussed before. 👍

🇫🇮Finland lauriii Finland

This isn't really all that relevant when using SDC in render array but when using SDCs within Twig. Twig doesn't have the concept of undefined unless you use Twig strict_variables turned on (which Drupal is not doing). So when you are passing in undefined properties, they become null. I don't think there's a practical way to keep the variables as undefined and really as a frontend developer, you shouldn't have to care.

🇫🇮Finland lauriii Finland
🇫🇮Finland lauriii Finland

Merged the follow-up! I also opened 📌 Add docs for image code component Active .

🇫🇮Finland lauriii Finland

lauriii created an issue.

🇫🇮Finland lauriii Finland

Merged! Thank you @heyyo for pushing this forward! 👏 We can still iterate on this so feel free to open follow-up issues with improvements!

🇫🇮Finland lauriii Finland
🇫🇮Finland lauriii Finland

Could we please split this to two separate issues? I'm not sure that adapted prop sources is what's needed here. You should be able to map date field to a format: date string. If that's not the case, that's a bug on it's own.

🇫🇮Finland lauriii Finland

lauriii created an issue.

🇫🇮Finland lauriii Finland

There's a small bug with this. After you delete a page, you are taken to a 404 page:

🇫🇮Finland lauriii Finland

Yep, admin theme should be a composer dependency and not part of the site template. I think a theme directory for the site template theme makes sense conceptually. It could be either a self-contained theme or a theme depending on another theme via composer dependency depending on the site template and its needs.

🇫🇮Finland lauriii Finland

I could argue this either way but based on seeing this issue it doesn't seem like people could have a good experience testing Canvas without having this fixed which is why I think it would be better if we could fix this before beta. Would be helpful to understand if this is something that's difficult for us to fix so that we can weigh the delay against the impact of this issue.

🇫🇮Finland lauriii Finland

Agreed that we should disable this before beta to avoid the BC break 👍

🇫🇮Finland lauriii Finland

I don't see how this is a data integrity concern? This seems like a UX concern and us trying to babysit the users. I feel very strongly that we should not introduce validation of this type. It should be up to the user to decide what kind of template they want to create. Maybe all of the data is fetched using JSON:API or maybe you just want to preview how a static template would look like? This isn't really changing from what you can do today either because you can create an empty display mode today and that's fine.

🇫🇮Finland lauriii Finland

I don't really see why this is something we would have to enforce. It's totally fine if users want to test static templates as content templates before they map props to a dynamic prop source.

🇫🇮Finland lauriii Finland

+1 for #44.

@d34dman Isn't the solution to what you're describing using categories / tags instead of specific components? I'm hesitant to add an alter hook for this because the DX of SDCs is intended to be as simple as possible and as the name suggest, everything related to a component should be found in a single directory.

🇫🇮Finland lauriii Finland

I'd recommend following as the comment because we will be making a broader public announcement later:

Experience Builder has been renamed to Drupal Canvas in preparation for its beta release. You can now track issues on the new project page here .

🇫🇮Finland lauriii Finland

+1 for landing the fix as it is but it would be great to plan for doing #24 🐛 After source session timeout, XB page stuck on the error message Active too.

🇫🇮Finland lauriii Finland

We need to adjust the errors that are displayed to user in this situation. This isn't really an unexpected error.. This is just the users session timing out?

🇫🇮Finland lauriii Finland

We should not be generating props with camel case. The prop in code is automatically converted to camel case from the prop name. We should either try to fix that here or in a follow-up.

🇫🇮Finland lauriii Finland

Yep, this seems like an oversight.

🇫🇮Finland lauriii Finland

What are those major implications? Is it purely code / architectural or is there implications to the end-user?

The goal is to keep the rendering similar between XB and Blocks so that same CSS works with both. I don’t think we want to maximize the compatibility at any cost, which is why it would be good to understand what adverse effects this has.

🇫🇮Finland lauriii Finland

I'm wondering if we're approaching images and implementing designs the right way. It doesn't look like even with the latest changes the design produced matches closely enough the original image.

I also don't think it makes sense that the image is visible in the chat. It's confusing to see a new image appear there that I didn't upload myself.

I'm also wondering if we should upload multiple images because some issues could happen on a specific breakpoint?

🇫🇮Finland lauriii Finland

I think a single permission for managing the segments is sufficient. 👍

🇫🇮Finland lauriii Finland

I'm not sure if that screenshot is because that's not what I'm seeing. This is how it looks for me:

This looks correct except we should reduce the spacing above the text.

🇫🇮Finland lauriii Finland

Great to see some progress on this! Some feedback:

  1. We should include implementing the designs for this as part of this issue; it looks currently too unpolished. I've attached video of the designs for this.
  2. We should never show the user "Calling X tool" or "Calling X agent". We need to always convert these to more user friendly messages.
🇫🇮Finland lauriii Finland

The changes look good and it gives a sense that we thought of both the pros and cons of these decisions 👍

🇫🇮Finland lauriii Finland

I guess DummyPropsEditForm will remain dummy 🙈

🇫🇮Finland lauriii Finland

Parent issue is already tracked as a stable blocker.

🇫🇮Finland lauriii Finland

Parent issue is already tracked as a stable blocker.

🇫🇮Finland lauriii Finland

Parent issue is already tracked as a stable blocker.

🇫🇮Finland lauriii Finland

Parent issue is already tracked as a stable blocker.

🇫🇮Finland lauriii Finland

Parent issue is already tracked as a stable blocker.

🇫🇮Finland lauriii Finland

Content Templates is still a priority for stable, but we're tracking it separately.

🇫🇮Finland lauriii Finland

It would be nice to fix this but this is not a stable blocker. I think slots would have to be considered black boxes until we have this.

🇫🇮Finland lauriii Finland

There's been some serious improvements in this area, thanks to @jessebaker 👏 I don't think the remaining work needs to block a stable release.

🇫🇮Finland lauriii Finland

This is an important usability improvement, but not a stable blocker.

🇫🇮Finland lauriii Finland

This is a nice improvement but not a stable blocker.

🇫🇮Finland lauriii Finland

This is tracked as part of the Content Templates, which is a priority for stable. However, the individual issues are not tracked as stable blockers.

🇫🇮Finland lauriii Finland

This is tracked as part of the Content Templates, which is a priority for stable. However, the individual issues are not tracked as stable blockers.

🇫🇮Finland lauriii Finland

I do think we should mimic the block rendering from \Drupal\block\BlockViewBuilder so that same CSS that works outside of XB works when using blocks in XB. Ideally we should do this before stable but I don't think this needs to block the stable release. Worst case we'd document this in known issues.

Production build 0.71.5 2024