Closed (fixed)
Project:
Paragraphs
Version:
8.x-1.x-dev
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
11 May 2017 at 23:45 UTC
Updated:
31 Jul 2017 at 23:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
toncic commentedFixed problem with JS. Uploading screenshot.
Comment #3
pivica commentedIndentation is not good in this part until the line 75.
We are in behavior here so we should use once() in order to avoid reattaching behaviors, something like
var $parWidgets = $('.field--widget-paragraphs', context).once('paragraphs-bodytabs');Not 100% sure but shouldn't we use // comments here and not doc block comments?
https://www.drupal.org/docs/develop/standards/javascript/javascript-codi...
> C style comments (/* */) and standard C++ comments (//) are both allowed.
So you should use /* or // but not /**
#content and #behavior elements are used on couple of places. We should create vars for them also.
Can we use $parTabs var here?
You can shorten this by writing
$mainRegion.removeClass('behavior-active content-active is-active');This does not looks good because it is searching the context, can we be more specific?
Comment #4
miro_dietiker@Ivica 6. -- Why is it not good to limit activity to the event context? Usually we need to do exactly that to properly support ajax actions and avoid double bindings.
Comment #5
pivica commented> @Ivica 6. -- Why is it not good to limit activity to the event context? Usually we need to do exactly that to properly support ajax actions and avoid double bindings.
I was just asking can we be more specific and instead of context use $parWidgets or some other var that is that holds that elements so execution is a little bit faster .
Comment #6
toncic commentedAddressed #3.
Comment #7
pivica commentedJS looks better, couple of more things:
I know drupal doc page says both // and /* are fine, but i've just checked all Drupal JS files in core/misc and all of them use // comment style. Can we please change then all code comments to // syntax.
Small thing you could do this in one line
$parWidget.removeClass('content-active').addClass('behavior-active');This is a jquery object so you should use $el instead of el.
One more thing, this is jQuery object of
thisso usually you use $this naming for this. Yeah too many 'this' in previous sentence ;)Also don't use jQuery(this) but do $(this). So
var $this = $(this);Comment #8
toncic commentedAddressed comment #7.
Comment #9
pivica commentedJS code looks good, didn't tested this so will not put into RTBC.
Comment #10
miro_dietikerPlease rebase. This patch contains at least one accidental revert.
Comment #11
toncic commentedRe-basing.
Comment #12
miro_dietikerAlmost. :-)
If you have two fields and the first one has paragraphs with behavior plugins, but the second hasn't... it still shows the perspective tabs to both fields, but it should only display the tabs to the first field.
Comment #13
toncic commentedTested a bit more with the same steps like you. Here it is screenshot:
We have two fields, one with Grid paragraph type which has behavior form and another one with Text paragraph type which has not behaviors form. Perspective tabs are presented only for first field.
Comment #14
toncic commentedPrevious rebase was wrong.
Comment #16
miro_dietikerYeah, tested the new reroll and it seems to work fine. Committed. :-)
Comment #17
miro_dietikerReverting this commit. It breaks deep nested behavior field visibility. Next time we do it right.
Comment #19
toncic commentedFixed problem with nested paragraph.
Comment #20
miro_dietikerI'll test this a bit on some production environment while working with content.
Comment #21
toncic commentedThere was a problem whit changing perspectives if we have more than one field e.g. 2 field and on both fields we are on the same tabs.
Fixed that.
Comment #22
miro_dietikerThis is not a reliable detection for the host entity. A paragraph field could be attached to any other host entity, for instance a term. And we need to test cover that case.
Other than that, it seems to do a good job while testing.
Comment #23
toncic commentedFixed problem from #22.
After discussion with @Berdir, we don't need test in this issue.
Comment #24
berdirThat's not what @Berdir said :)
He said we don't need to test this node vs user stuff because that check was bogus anyway and there is no such code anymore.
We can check the correct adding of the nested class and we if we change which parts are visible vs not, then we can possibly also extend the JS test with that.
Comment #25
toncic commentedAdded tests.
Comment #26
berdirIt's not quite clear to me how this would fail, please provide a test-only patch.
Comment #27
toncic commentedTest only patch.
Comment #28
berdirNeeds work for discussed test improvements.
Comment #29
toncic commentedImproved test but didn't test. Let's see what test bot will say.
Comment #30
berdirWorked on the test together with @toncic.
Comment #32
miro_dietikerCommited, while fixing some codestyle things and comments.