People compare Paragraphs with Atoms.
Some things are very similar. Others are different.
With Drupal 8, Paragraphs improved a lot and also made some gaps smaller.
The maintainers at Atoms is interested in talking about collaboration...
https://github.com/tonystar/drupal-atoms/issues/25
We should start outlining the key architectural differences and figure out if we want to address them...
If we want to go a step further, we could start creating an issue component "Difference to Atoms" and create issues per major finding. Then we can decide to won't fix or patch if we want to support it.
As a first step, we should possibly roughly check overlaps and document them as bullets in this issue to figure out if we want to go ahead or not.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | paragraphs-as-bricks.png | 282.82 KB | anton-staroverov |
Comments
Comment #2
jeroen.b commentedtonystar already created an issue about that some time ago #2494259: Like Paragraphs but probably more flexible/perspective, maybe he never responded due to my direct response ;)
I'm thinking that a fully ported D7 version should be 1.x (including the "Needs fix before Drupal 8 Release" tagged issues fixed).
I'd be happy to discuss a merge with atoms in 2.x, only thing I don't like about it is that it's fully based on ECK, since Entities are way better in Drupal 8, I don't think we need ECK.
Comment #3
miro_dietikerDiscussed and decided about reusability.
Atoms is designed around that concept. If anything like a merge is going to happen, then we need a separate content type (Atom or Reusable Paragraph) that allows management of the situation.
Atoms could also provide an alternate widget... We also need to check usage of IEF and other modern components.
Clearly, a merge would need redesign to gain the most valuable solution without exponential complexity and avoiding duplicated code, ...
I would much appreciate to see room for atoms emerging as a submodule that picks up the workflow around paragraphs reusability (as a separate entity, with added metadata and nice UI integration).
Comment #4
miro_dietikerAtoms was renamed to Bricks
https://bricks.tonystar.me
https://www.drupal.org/project/bricks
Wrote the maintainer about my proposal.
Comment #5
miro_dietikerThe recent proposal with our UX work will outperform this issue / requirement.
With Paragraphs adopting the library concept, Paragraphs will be capable to cover all use cases of Bricks.
#2414865: [META] Reuse paragraphs / Library
Combined with behavior plugins (grid, slider, ..) we will be very powerful to build a variety of content.
#2828506: Introduce a plugin system for paragraphs types
With paragraph types collection, we will deliver a feature rich set of tools out of the box.
https://www.drupal.org/project/paragraphs_collection
The UX with paragraphs is already, and will be much improved compared to Bricks. Paragraphs strives to be user centric and the current iterations are highly focussed on content creation experience - meaning reduction and simplification.
All these things of our proposal are well accessible on our presentation from the last Drupal User Group meeting:
http://www.md-systems.ch/en/blog/business/2016/11/10/media-seo-and-parag...
I'm still highly open to collaborate with Bricks' maintainers. IMHO, with all our Paragraphs Future proposals, Paragraphs can also be a better Bricks. ;-)
Comment #6
miro_dietikerComment #7
anton-staroverov commentedHi there! I just completed the 8.x version of Bricks: https://www.drupal.org/project/bricks!
I took in account your suggestions and created an abstract Entity Reference Widget "Bricks tree (Inline)" - so it works well with Paragraphs entities!
Also, I found this slide, and now it's working with Bricks+Paragraphs:
Compare it to current Bricks UI:
So- reopening the issue to continue the discussion and to define next steps!
Comment #8
adubovskoy commentedThat's intresting for me. Because bricks better for layout tasks, but paragraphs more popular. It's good to have one solution. ++ for merge.
Comment #9
miro_dietikerParagraphs was well progressed and had a stable code base with an early focus on storage and missing concepts such as composite via ERR.
The idea of this issue was to avoid duplicate work, but the direction of Bricks is obvious. It is striving for independence and released a stable version.
Paragraphs won't merge with Bricks. The only potential direction here is in case Bricks is abandoned one day.
Thus marking this won't fix on our side.