Refactor /issues/new view endpoint

[miketaylr]

This method is a bit long and messy now (especially once https://github.com/webcompat/webcompat.com/pull/1198 lands). It's ready for a refactor.

See the suggestions at https://github.com/webcompat/webcompat.com/pull/1198#discussion_r83341295.

[miketaylr]

https://github.com/webcompat/webcompat.com/blob/master/webcompat/views.py#L157-L210

[karlcow]

This is slightly more stable https://github.com/webcompat/webcompat.com/blob/f88375baac0029560da45951833894785fc99210/webcompat/views.py#L211-L322

or basically search for /issues/new route in webcompat/views.py

[karlcow]

This route contains:

• push caching for CSS with HTTP/2
• logging
• user logged or not. see #3329
• check the request type

Then processing start:

• with 6 return
• and 4 abort

so yes indeed this is a bit complicated. I need to draw what it does. A very simple step could be just to create functions that remove everything which is not web related.

Question: should most of the engineering be moved to issues.py? or a new.py module?

Basically we could just do this:

@app.route('/issues/new', methods=['GET', 'POST'])
def create_issue():
    """Create a new issue or prefill a form for submission."""
    log = app.logger
    log.setLevel(logging.INFO)
    if g.user:
        get_user_info()
    return process_new(request)

Then deal with specific functions for each of the steps. That would also make the testing much more simple.

[karlcow]

even logging could be probably elsewhere.

[karlcow]

additional Thoughts on why it's important to refactor by extracting into functions. https://hakibenita.com/python-dependency-injection

By making modular functions we do not depend on creating fake request to test what the view should do. we just need to test input/output.