Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm refactoring some custom JavaScript modules written to support our mapping functionality. I'm looking to make them much more unit-testable and be able to plug pieces in and out more easily.

My question is related to having UI manipulation and business logic be in the same module. I know that having the UI part makes unit testing a little more difficult. I would think also decoupling the UI part would enable other people to add their own UI layer if they wanted to change the look and feel while still keeping the core functionality.

Edit: I'm more working with Dojo modules since that what the mapping API is built on top of. I figured since Dojo comes with it we would use that. I'm finding that Dojo modules don't lend themselves to being easily tested (I tried using Doh and it is the most unintuitive testing framework I've ever worked with). I'm thinking of making more vanilla JS modules and only tried to use what I absolutely need to from Dojo. That's where I got the idea to maybe separate the UI layer from the logic for each module as well.

Does anyone have suggestions on how those can be decoupled?

share|improve this question
    
This is a bit vague... Can you be more specific about the particular problem you're trying to solve? –  Robert Harvey Jan 22 '14 at 1:46
    
@RobertHarvey Sorry about that. I'll add specifics. –  Justin Chmura Jan 22 '14 at 13:29

1 Answer 1

Keep your data in HTML, your styles in CSS, and your interactions in JS.

What this means is that you'll need to toggle styling hooks, such as classes or attributes to change the UI state. That way, when you want to change how the UI looks, you only need to update CSS, and can generally avoid script changes.

There will be a few cases where you may need to animate a style via JS. Particularly for positioning. Try to keep the JavaScript focused on the state of the code, rather than how it should look. When you go to unit test, it'll give you something concrete to check for. I.E. manually trigger an event on an element in a widget, and check that the widget entered the appropriate state from that event by checking that it has the right classes and attribute values.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.