/****************************************************************************
**
** Copyright (C) 2020 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of the Qt Design Studio documentation.
**
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
**
****************************************************************************/

/*!
    \page studio-qtquick-best-practices.html
    \if defined(qtdesignstudio)
    \previouspage {Tutorials}
    \nextpage studio-optimized-3d-scenes.html
    \else
    \previouspage creator-usability.html
    \nextpage studio-optimized-3d-scenes.html
    \endif

    \title Qt Quick Best Practices

    The following guidelines describe the most efficient ways to use \QC to
    create UIs and scenes that run flawlessly on the intended platforms.

    For best practices in creating 3D scenes with optimized graphics
    performance, see \l {Creating Optimized 3D Scenes}.

    \if defined(qtdesignstudio)
    For guidelines on how to achieve best results when importing assets, see
    \l {Exporting from Design Tools}.
    \endif

    \section1 Naming Conventions

    Establish naming conventions to keep the components in your UI organized.
    Name your components accurately and give them suitable IDs. You should
    manually specify the names of the components you export from design tools to
    create reliable and self-explanatory names that follow the naming
    conventions you have established.

    For example, a button symbol might have the ID \e myButton_symbol and the
    different layers might have it as a prefix with the states appended, thus
    producing IDs such as \e myButton_symbol_default. To prepare for additional
    mouse areas later in the project, you could use similar IDs for them, such
    as \e myButton_symbol_hotspot. When you use the button as instances in a
    screen, you would give each of these instances a unique ID that relates to
    that screen. For example, \e myButton_myMenu_home, \e myButton_myMenu_profile,
    and \e myButton_myMenu_settings

    \section1 Planning the UI

    Plan your UI properly. Know what elements, such as screens, components,
    and states, you need. Creating a descriptive wireframe and acquiring a
    detailed UI specification before you start will make the process of creating
    the UI more efficient.

    \section1 Using Components Economically

    It is important to understand the performance costs associated with using
    components.

    To use components efficiently and economically:

    \list
        \li Componentize your design by packaging your resources into reusable
            components that can be conveniently recombined to suit the needs of
            your UI.
        \li Use as few components as necessary. To minimize the number of
            components, use \l{Adding Property Aliases}{alias properties} and
            \l{Adding States}{states} to create the differences in your
            component instances. We recommend reusing components
            instead of duplicating them, so the components do not need to be
            processed as completely new component types. This reduces loading
            and compilation time as well as the size of the binary.
        \li Any content that is data-driven should be
            \l {Using UI Files}{exported as a public property} of the
            relevant component. For example, a speedometer should have an \c int
            or \c real property for speed to which the UI is bound.
        \li Separate UI from the application logic. Designers should work with
            the \l{UI Files}{UI files} (.ui.qml), while developers should work
            on the corresponding implementation files (.qml) to define their
            programmatic behaviors or JavaScript. This enables iteration from
            both the design and development side of the process without the the
            risk of overwriting each other's work.
    \endlist
*/
