Skip to content
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

Possibility of changing the opening/closing symbols for template tags #27

Open
scriptogre opened this issue Dec 9, 2022 · 7 comments
Open

Comments

@scriptogre
Copy link

scriptogre commented Dec 9, 2022

Hello creator(s) of Slippers!

I have heard about your project from this guy on YouTube, BugBytes:
https://www.youtube.com/watch?v=oC1K8IKK3Vo

I was excited to use it but was disappointed to see my IDE (IntelliJ) refusing to accept the newly created template tags.

Prefixing any tag with a special character (besides underscores _ and dashes - ) throws out errors from the inspector.

After days of trying, I haven't found a way to disable the inspector for that specific error.
Nor could I register the symbol-containing tags by creating some kind of new rule.
It just didn't work.

I just lived with it, but after a couple of days of writing templates full of fake errors, I got so bugged out that I gave up and looked for an alternative.

Then I found django-components, which did a similar job to Slippers, but in my opinion, is way too verbose and so I came back to slippers.

Unfortunately, picking up another IDE is not an option after years of getting used to it.
So this time, I tried to fix this issue by monkey-patching the code inside templatetags/slippers.py (really ran out of options).

OPENING_SYMBOL = "__"
CLOSING_SYMBOL = "___"


# Copied from slippers source code
#
# Replaces opening / closing symbols for tags
# #card and /card --> __card and ___card
#
# Fixes IntelliJ IDE template inspector throwing errors

# Component tags
def create_component_tag(template_path):
    def do_component(parser, token):
        tag_name, *remaining_bits = token.split_contents()

        # Block components start with OPENING_SYMBOL
        # Expect a closing tag
        if tag_name.startswith(OPENING_SYMBOL):
            nodelist = parser.parse((f"{CLOSING_SYMBOL}{tag_name[len(CLOSING_SYMBOL):]}",))
            parser.delete_first_token()
        else:
            nodelist = None

For motives unbeknownst to me, the template tags won't be registered when applying this monkey patch, but I have not given up on this solution yet and would come up with a pull request once everything is working well.

Any chance of adding the option to change the template tag prefixes (possibly using a settings.py variable)?

Massive respect for creating this library,
Chris, a slippers fan :)

@SebastianDix
Copy link

Exactly my situation!

@weilharter
Copy link

weilharter commented Aug 6, 2023

The startTag # and endTag / is a very exotic solution and therefore not a good design decision in terms of IDE/Syntax Highlighting support.

@mixxorz I'd suggest to add another component format with better support:

similar to django-components:

{% component "calendar" date="2020-06-06" %}
   Foobar
{% endcomponent %}

instead of

{% #calendar date="2020-06-06" %}
   Foobar
{% /calendar %}

@jmuncaster
Copy link

jmuncaster commented Aug 7, 2023

Love this library, but also would love to see different or customizable open/close tags and agree # and / are exotic.

I think the most idiomatic would be something like:

{% calendar date="2020-06-06" %}
Child
{% endcalendar %}

But the inline syntax is not obvious. Perhaps some suffix would do the trick? Like:

{% calendar_ date="2020-06-06" %}

I also like @weilharter 's proposal.

If nothing else, the ability to customize the open/close tags to be more IDE-friendly would be great.

@mixxorz
Copy link
Owner

mixxorz commented Aug 7, 2023

I will admit the syntax is a bit of a hack, but it's one that works with DTL.

I think the root of the problem isn't the syntax, but lack of IDE support which I am aware.

There is technically enough code that can be statically analyzed in components.yaml and the as yet undocumented front-matter type definitions (#25) to make a really good IDE integration. (Component completion, go to definition, component parameter hints, etc.) Hopefully someone (or me) would make that one day.

I'm not closing the door on a different way to use the components though. Suggestions are welcome.

@SebastianDix
Copy link

SebastianDix commented Aug 17, 2023

I will admit the syntax is a bit of a hack, but it's one that works with DTL.

I think the root of the problem isn't the syntax, but lack of IDE support which I am aware.

There is technically enough code that can be statically analyzed in components.yaml and the as yet undocumented front-matter type definitions (#25) to make a really good IDE integration. (Component completion, go to definition, component parameter hints, etc.) Hopefully someone (or me) would make that one day.

I'm not closing the door on a different way to use the components though. Suggestions are welcome.

This is a Python / Django library. PyCharm is probably the most popular (paid) IDE and probably the most 'pro' IDE for Python out there. PyCharm will not change for Slippers that easily and a good IDE integration seems overkill.

What is preventing us from using the @scriptogre solution it so that the opening and closing tags are configurable to be normal {% slipper "component_name" %} {% endslipper "component_name" %} tags which will be properly supported and indented by all IDEs? :-) (I know I can make a PR myself, but I probably didn't study the innards of this library enough and it's been some months since I last looked at the source, so I ask the author first, but was thinking of making this my first open-source contribution since I like the idea of this library a lot)

@IanLuan
Copy link

IanLuan commented Sep 1, 2023

In my opinion, we could get rid of inline components to improve the developer experience.

# block component 
{% card %}

{% endcard %}

or

# inline component
{% card %}{% endcard %}

This way just adds the need to close the tag, but I believe it's still much better than # and /.

@nanuxbe
Copy link

nanuxbe commented Sep 8, 2023

There is currently a draft PR in progress to support adding @weilharter 's proposed syntax here: #55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants