jimmy2020

EZeats (ez-eats.com)| Software Engineers | On-site in Cairo, Egypt (remote possible in MENA region)

We are shaping the future of F&B and contactless dining with a cutting-edge POS tailored for the MENA region.

Open Roles:

- Senior Backend Developer (NestJS): Expert in architecting scalable backend systems using NestJS, with deep proficiency in cloud platforms, microservices, and API optimization. Collaborates with cross-functional teams to deliver secure, high-performance solutions aligned with industry best practices.

- Senior React Native Mobile Developer: Skilled in building cross-platform mobile apps with React Native, focusing on performance optimization, third-party integrations, and CI/CD pipelines. Partners with designers and product teams to craft intuitive, user-centric mobile experiences.

- Senior UI/UX Designer (F&B Products): Specializes in creating visually compelling, user-friendly interfaces for food and beverage platforms, leveraging user research, wireframing, and prototyping. Balances brand identity with usability to drive customer engagement and business growth.

- Senior Product Manager (F&B Products): Leads end-to-end product strategy for F&B digital solutions, from market analysis to roadmap execution. Bridges stakeholder needs with technical teams to innovate and scale products in a competitive industry landscape.

if you are interested send your resume to careers@ez-eats.com with the job position in the title.

Excellent point. Thank you.

Thank you!

The original document initially mentioned the 'software industry' and I indicated that by signing it, I would be legally agreeing not to work in the software industry at all. They mentioned they would provide a more specific definition, but I still found it unusual. I understand signing an NDA, but a non-compete agreement feels more like giving them the right to sue me if they choose to.

I am outside the US, and they told me this is the common practice for startups now, and to be honest, I don't feel comfortable signing it.

That's what I am trying to say. Personally, I don't mind if my code is being used for commercial or not. I do mind when Microsoft uses my code without a reference and asks me to pay for copilot just because they decided to put it behind a paywall.

Still, it's good to be an option. If you see this as an advancement you can choose something like MIT if you don't like your code to be trained by a paid copilot then you can choose something like MIT-Human only.

It's a better solution than don't use GitHub at all. And whether we like it or not, a new license should be introduced to address the new data model.

There should be a new open-source license specifically designed to restrict the use of code for commercial purposes, whether it involves training machine learning models or not. It could be similar to GPL but tailored specifically for the field of machine learning, ensuring that the code cannot be utilized for ML commercial purposes or trained without limitation.

The entire package bundled and minified is ~14.4kb. No extra dependency needed. Just one package `@dflex/dnd`.

Thanks for pointing out the accessibility issue. DFlex stands for a better user experience that includes of course adding accessibility to the main mechanism. At least the essential one. But at this moment, the project is still in development mode and many things need to improve including accessibility.

Sorry for the bad experience and thanks for the feedback.

It makes sense I was also thinking "interactive" as well.

Glad it does. Thanks for the feedback.

It's not the size of the package. DFlex is actually small compared to other libraries. But I need to reconsider the size of the demo container before updating the version because when you resize there's a possibility to add a scroll to the container. Adding/removing scroll while dragging is not shipped yet.

Demos in the site are behind the current version and not being updated to the latest one [1]. And updating the demos will take a while since I have to take resizing containers into consideration. So the current version is 2.x.x while the last one was 3.7.0. Sorry about that.

[1] - https://github.com/dflex-js/dflex/pull/573

Thanks for sharing the link I'll look into it soon.

In the drag-and-drop context, an interactive element is an element that can traverse the DOM tree and change its position without causing a layout shift and with a proper reconciler and transformation mechanism.

Cloning elements and duplicating containers are what DFlex tries to avoid. Because the usual implementation is to clone the element (ghost it) and then append a new one with a fixed position. The result is to reconstruct the DOM tree directly with every user interaction which leads to poor user experience and not a very practical transformation. That's why the default thing to do with DFlex is not to clone or change the element position unless there's a need to do so, for example: transforming from a container with a scroll.

Happy to consider any suggestion you have.

In the nutshell, it's designed to drag an element into a droppable area. So let's say you are dragging a file to be uploaded, in this case, it makes perfect sense to use HTML API. Otherwise, you need a framework that can orchestrate the transformation. It's like using React. In theory, you can manipulate DOM directly in the browser but instead, you use a framework to build your app.

DFlex doesn't reorder the elements. 1- It transforms elements by calculating the new position so it can avoid any layout shift this is something essential in the transformation mechanism. 2- It reconciles the transformed element when needed. So instead of replacing the entire children, it replaces only the transformed ones.

Good question. Internally every registered element has a grid position inside its own container [1]. And it's not CSS grid styling, it actually calculates the geometry in each element and positioned them relative to their parent container. This is the implementation behind the enhanced transformation. Based on the grid position, DFlex can call the right method responsible for transformation instead of checking siblings linearly. For example, if you transform an element in the middle of the container it only invokes the switching position method instead of iteration in the entire tree. Still, grid implementation is not fully implemented and supported yet. But it's something that can be done in the next releases. However, the link you shared has an interesting case because you are resizing the element when appending it to the new container. I'd like to see a repo if it's possible but it's a very interesting case I'd love to look into it.

[1]- https://github.com/dflex-js/dflex/blob/cbda61af185100a3afb39...

I should add this comment as a description in the main readme :)

What makes it modern is how it's built and what makes web apps modern today. Its features make it modern, I am not sure why you suggest it's needlessly resource-heavy.

Sorry for not updating the demo included on the site. But scrolling is working in the newer version. Also, DFlex is not meant for uploading assets to the browser otherwise, it's the future of interactive apps when elements can be transformed and positioned smoothly. This is what I am trying to achieve with DFlex that's why I spent so much time figuring out the optimal solution for reconciling a transformed element instead of adding a layer to html5 and call it a day.

Thanks for the feedback. DnD kit is amazing and the initial library also is so powerful [1]. But we still need a comprehensive solution. Committing changes to DOM with each interaction and shadow caching is not a sustainable solution for building interactive apps. React or any other framework is not designed for interactivity. So even if you are using React you are not actually getting the benefit of React to reconcile because you still committing changes directly to DOM. That's why I built DFlex which has its own reconciler and transformation mechanism.

[1]: https://shopify.github.io/draggable/

As I mentioned in the readme it's a work in progress. But every feature that's shipped is tested with Chrome, Firefox, and Webkit [1]. I'd like to get your feedback though so if you want to open an issue I'll be happy to deal with it.

[1] https://github.com/dflex-js/dflex/actions/runs/3025464183

It's designed to handle nesting, so each register element can have depth starting from zero. But it's not finished yet. There are so many aspects to cover but nesting is not fully implemented. My priority right now is to enhance scrolling and migrate between scroll containers.

Edit: I'd like also to hear back from the community, I welcome any suggestions about the roadmap and what's necessary to be shipped soon.

You are invited to try and give me your feedback or work on any issues you have. The playground and the end-to-end tests are done entirely with React. I am not sure why you suggest it's not going to work with it. Also, it has to be done this way, since how to reconcile transformation is different from than usual reconciler algorithm.

What do you suggest?