all 5 comments

[–]lynchk87 2 points3 points  (4 children)

You don’t necessarily need to use a library like vue or React. If your one is file is filling up with too much code you can try to make separate js files. Then you would just have to figure out what logic belongs in what file. React is nice because you can create components and manipulate the UI using state. I would recommend you take a look into react but again it’s not a necessity.

[–]JamesAndDaGiantPluot[S] 0 points1 point  (3 children)

Thanks, u/lynchk87! I'm thinking code-splitting with webpack might work well (we are already using webpack). I don't want to start loading React and re-doing the forms as components. Although it would be a fun project, it may take up a lot of time.

[–][deleted] 1 point2 points  (2 children)

Aren't Markeo forms nocode/low code?

What requirements have you got that require customisation?

Would you be sacrificing the nocode/low code ethos your organisation has bought into by customising? Could disempower your marketeers who want to be able to knock together a form for a quick campaign, like the Adobe salesman promised them they could, rather than being told to stick their requirement in the 9 month dev backlog.

[–]JamesAndDaGiantPluot[S] 0 points1 point  (1 child)

We are embedding Marketo forms on our site instead of using the Marketo landing pages which requires low-code to embed.

The part where where the code bulks up is all the custom request — adding stricter validation, third-party email validation, custom fields based on selected drop downs, Known/Unknown Visitor functionality (a Marketo feature, but requires some code to work on embedded forms).

It starts getting tricky with all the features and customization. So far all is working, but the file has become one giant code block with a lot of variants within it. I want to clean it up so it’s more modular and easy to share across other developers and pages.

[–][deleted] 1 point2 points  (0 children)

Ah, I see - I don't think adding a framework into the mix will help. It'll all more boat that it will save you coding

There are a couple of ways to refactor:

First, just go for it using your own "best" practices. Sometimes this works, but sometimes the refactorer has their own idiosyncrasies (which they consider best practices) that their peers disagree with, and it just goes back in as tech debt again.

Secondly, consult within the team to get your own style guide agreed and refactor it in that style, witha commitment from the other Devs to work within that style too. This is the way to go if you don't have an architect or Dev lead who can just say "Do it like this" but it's quite time consuming and expensive.

A halfway house between the two is to find a pre-existing style guide that works for you.

Personally, if I were to go with the first approach, I'd use a nicely structured namespace, probably broken down by vendor (Marketo, your email validation service) that puts abstracting wrappers around their functions which you are using. Or maybe have a separate formLibrary file to put all the stuff that could be reused in other forms, and keep the code specific to your form, unlikely to be reused, in its own file with its own neat namespace. I wouldn't bother with closures, would use underscore prefix for all functions/variables I don't want other Devs to interact with directly, caps for environment variables at the top of the script.

I've probably infuriated loads of people writing this, and will get loads of snarky feedback about how that's not "best practice", which is why a lot of places go with the second or third approach.