๐Ÿ‡ฎ๐Ÿ‡ณIndia @meghasharma

Account created on 29 January 2020, about 5 years ago
  • Engineer - Frontend at QED42 
#

Merge Requests

More

Recent comments

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Updated the regex to apply case-insensitivity only to the file extension part using (?i:...) instead of applying it globally.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Updated the regex for image-uri and stream-wrapper-image-uri to be case-insensitive using the (?i) flag.
This allows image extensions like .JPG, .PNG, etc., from Media Library to work correctly and fixes the Twig rendering error.
Please review, Let me know if thereโ€™s a better approach we should consider.
Thanks @dhruv.mittal for the helpful suggestion!

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Converted all ConfigEntityType plugins to use PHP 8 attributes instead of annotations.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Renamed `PropSourceComponent.field_data` to `.propSources`.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Renamed state, prop and component data attributes.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Added a "Components" tab under the Appearance section and updated the "Enabled Components" and "Disabled Components" tabs under the "Components" section by adding the parent_id., Moved "Page builder components" listing in Structure to "Components" in Appearance.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Changes Done:
Updated Permission: experience_builder.component.status now uses the administer themes permission.
Updated Links: Changed /admin/structure/component to /admin/appearance/component in component entity definition links.
Removed "Page Builder Components" from Structure.
Please review

Now:
You can see the list of enabled and disabled components at /admin/appearance/component.

Remaining Task:
Add a "Components" tab under the Appearance section.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Could you please add some more details to the issue description? It would be helpful to have more clarity on the expected behavior and a proposed solution.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

meghasharma โ†’ made their first commit to this issueโ€™s fork.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Fixed the issue where long component names were overflowing the badge. Now, the text stays within bounds and displays correctly. Ready for review.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

This is already implemented in the file. The datetime fieldโ€™s date and the file_uri fieldโ€™s url are handled the same way as daterange in tests/src/Kernel/EcosystemSupport/FieldTypeSupportTest.php.

'datetime' => [  
  // ๐Ÿ› Core bug: this is the computed equivalent of `value`, should be marked internal.  
  // @todo Give this similar treatment as `daterange` in https://www.drupal.org/project/experience_builder/issues/3512853  
  'date' => FALSE,  
],  
'file_uri' => [  
  // ๐Ÿ› Core bug: this is the computed equivalent of `value`, should be marked internal.  
  // @todo Give this similar treatment as `daterange` in https://www.drupal.org/project/experience_builder/issues/3512853  
  'url' => FALSE,  
],  

Let me know if anything else is needed. Thanks!

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Marked 'date' (DateTimeItem) and 'url' (FileUriItem) properties as internal
Created DateTimeItemOverride.php to override DateTimeItem and marked the date property as internal.
Updated FileUriItemOverride.php (already present) to mark the url property as internal.
Please review

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Tried conditionally rendering the div using {initialized &&

...

} instead of just applying display: none, but the issue persists. The console still shows the 'Infinity' warning for height. Keeping the original approach with isFinite checks seems to work.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Instead of directly manipulating the DOM using document.querySelector and menu.style.display = 'none' (lines 84 and 88), we should use Radix UIโ€™s built-in method (if available) to close the menu.

Can we avoid direct DOM manipulation? Radix UI might change internal class names, which can break the code.
Can we use state for menu visibility? The menuโ€™s visibility should be controlled using useState.

const [open, setOpen] = useState(true); // Control menu state

const closeContextMenu = useCallback(() => {
  setOpen(false); // Close the menu using state
}, []);
๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I have updated @typescript-eslint/eslint-plugin and @typescript-eslint/parser to 8.26.0 as per the issue requirement.
Installed versions:
@typescript-eslint/eslint-plugin: 8.26.0
@typescript-eslint/parser: 8.26.0

After updating, I ran npm run lint:eslint and encountered the following error:

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

After running npm run lint:eslint, I still see the same warning that was present earlier:
Should we now check if we can update to a newer version of @typescript-eslint to resolve this?

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I have upgraded TypeScript to version 5.6.3 as per the discussion.
Verified with: npx tsc --version and npm list typescript
Ran npm install to ensure dependencies are correctly installed

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Yes @wim leers, This can happen when rect.height * canvasViewPortScale results in Infinity. This usually occurs if rect.height has an extremely large value or if canvasViewPortScale is not properly defined.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Updated MR to resolve the console error for one and two column components. Let me know if any further adjustments are needed.
Thanks @omkar-pd

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I have updated the merge request to resolve the console error. Now, when we drag and drop a component in the canvas, no warning appears in the console. Please review and let me know if any further changes are needed. Thanks!

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I have reviewed the merge request after switching to the issue branch.
- The code now correctly separates FormElement and FormElementDescription from DrupalFormElement.tsx, making it cleaner and easier to reuse.
- The new components follow the existing structure and naming rules.
- Everything working as expectedโ€”labels, descriptions, errors, and attributes are handled properly.
Looks good to me!

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I am not able to reproduce the console error related to Drupal.announce.
I added an image component, selected an image from existing media uploads, and checked the console, but I didn't see any error.
This might have been fixed in another issue.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I tested this issue locally and found that updating only ComponentOverlay.tsx resolved the warning. The issue occurred because an Infinity value was being assigned to the height CSS property. After modifying ComponentOverlay.tsx to ensure only finite and positive values using isFinite(), the warning no longer appears when dragging and dropping a component.

To fix this, update the style attribute at line number 261 in the ComponentOverlay.tsx file. This ensures rect.height * canvasViewPortScale is a valid finite number before assigning it to height.

style={{
  display: initialized ? '' : 'none',
  height: isFinite(rect.height * canvasViewPortScale) && rect.height * canvasViewPortScale > 0
    ? rect.height * canvasViewPortScale
    : 'auto',
  width: isFinite(rect.width * canvasViewPortScale) && rect.width * canvasViewPortScale > 0
    ? rect.width * canvasViewPortScale
    : 'auto',
  top: isFinite(elementOffset.verticalDistance * canvasViewPortScale)
    ? elementOffset.verticalDistance * canvasViewPortScale
    : 0,
  left: isFinite(elementOffset.horizontalDistance * canvasViewPortScale)
    ? elementOffset.horizontalDistance * canvasViewPortScale
    : 0,
}}
๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I tested this issue on my local setup.
Before applying the fix, block names in the component list were encoded (e.g., Who's online block).
Some weird characters were appearing after "who" in the names.
After switching to the issue branch, I verified that the block names are now correctly decoded and displayed properly.
API Response: /xb/api/config/component now returns correctly decoded block names.
Example: "Who's new block" now appears correctly instead of the encoded version.
Everything seems to be working fine. Looks good from my side!

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Yes, children is a reserved prop in React, and using it as a slot name in Experience Builder is causing conflicts.
I am exploring this issue and trying to understand the best way to fix it. If anyone has suggestions on the correct approach for renaming the slot, I would like to learn more.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

I tested this issue on my local setup. Before checking out this branch, pressing Enter in the 'Add new code component' modal was not submitting the form, and I had to manually click the 'Add' button.
After switching to the issue branch, I verified that pressing Enter now successfully submits the form without needing to click the button.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Hello @here, Commit is successfully removing the hyphens: auto from css & .pcss.css files. Looks good to me., So moving it to RTBC++. Thanks!.

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Added dark circle to active state when it's active as per the figma design.
Please review
Thanks!
Screenshot 2024-04-16 at 2.46.36 PM
Screenshot 2024-04-16 at 2.46.53 PM

๐Ÿ‡ฎ๐Ÿ‡ณIndia meghasharma

Megha Sharma
had the opportunity to volunteer on registeration desk
I have registered for most of the Attendee's. and I made goodie bags. I gave out welcome kits.

Production build 0.71.5 2024