Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(dashboard): restore email editor 'for' block #7483
feat(dashboard): restore email editor 'for' block #7483
Changes from 1 commit
3414ba5
7e1a59b
beae876
24f87b8
009d9ad
18fd649
f851d8d
fee034e
04463d7
7c6384c
9c8d4a5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Show is an Attribute, not a node. So to be precise we should name this as
handleShowAttr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even more precise would be handleNodeByShowAttr because here we decide if to show a Node based on an attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to disagree here, I think this way the naming is more common and understandable.
We are processing nodes and the
for
andshow
are a specific type of nodes. We are not processing the attribute only, we are processing an entire node which hasattr = "for"
, similar asstep.type = "email"
.When you first time look at this method, its clear that if the node is of type
for
you do something with the node - you dont need to know about some internal property name such asattr
or anything:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about handleEach, handleShow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here we do not need to getValueByPath, id suggest doing the following:
go to variableAttributeConfig
add a new entry,
{ attr: MailyAttrsEnum.EACH, flag: MailyAttrsEnum.EACH }
the result will be that in the pipeline we will wrap each attribute (node.attrs.each) with
{{...}}
then you could get the value from the variable using liquid js.
let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, iterableArray accepts and returns this:
What you are suggesting, would return just the iterable path string, not the actual array:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if i understand it should return an array.
Editor:
Variable:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It currently doesnt work like this because we dont have
for block {{ payload.comments }}
anywhere in the maily json, we have justeach: {{ payload.comments}}
. That said its interesting idea to explore I will have a look if we can do this separately.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for
semantics representation aside, this one should work, doesn't it?we have
each: {{ payload.comments}}
with data variables:
{"payload":{"comments":[" a_1 "," a_2 "," a_3 "]}}
once we execute
const iterableArray = await parseLiquid(iterablePath as string, variables);
we should get the array
[" a_1 "," a_2 "," a_3 "]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the placeholders (
{{payload.something}}
) are not liquid output right? They are more Liquid input, since the parsing by Liquid happens later and this is usecase is an input for that:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Liquid JS calls the value with filters wrapped with
{{...}}
an Output i using Output instead of placeholder would help us unify and help us to understand each other better.and the main logic in this function is
newNode.text = nodePlaceholder.replace(iterablePath,
${iterablePath}[${index}]);
which creates a liquid js Output.
Let me know what you think about it.
In addition, apologies for missing this earlier I noticed that we are using
string.replace
. Instead, we should usewrapInLiquidOutput
whenever we have a Mailyfallback
attribute.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was there a specific reason for this change? When parsing the
variable
type from Maily, we need to convert it totext
because Liquid is responsible for variable parsing.in addition, this helps us avoid any side effects from Maily's variable parsing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is required for the 'for' logic down the line. The output from this hydrate schema usecase looks something like this:
If it would be replaced by
type: text
here, I wouldn't be able to know which node isvariable
and whichtext
, therefore I wouldn't be able to transform the variable here from{{ payload.comments.text }}
to{{ payload.comments[0].text }}