Skip to main content

Troubleshooting Guide for Issue Reporting

When you encounter issues while building applications with WeDa Low-Code and wish to ask questions in the community or seek assistance from relevant developers, first clearly and concisely describe the problem, and ideally provide a sample that can reproduce the issue.

Question Template​

  • Problem Description: Please clearly and concisely describe the issue and the expected result.
  • Runtime Environment:
    • In-editor environment, such as preview area/edit area/mobile end/pc end/mini program end
    • Post-release runtime platform, such as mobile end/pc end/mini program end
    • Browser, such as Google, safari, WeCom internal access, etc.
    • Operating system, such as MacOS, Windows, Android, ios, etc.
  • Exception Information:
    • Provide relevant error messages via screenshots or screen recordings, and please copy the complete error information
    • Source of error information: error logs in the console, error messages from the platform, or others.
  • Real-time preview link: In the WeDa Editor, you can generate a real-time preview link for either the home page or the current page. Please copy the real-time preview address.

Self-Service Troubleshooting Guide​

A reproducible example that directly demonstrates the issue helps R&D personnel locate the problem more quickly and conveniently, thus responding and resolving it promptly. It also helps you perform self-checks to rule out unexpected results caused by your usage. How to build a simple problem example, you can refer to the following principles:

Reference Principles
  1. Complete — having the necessary code and configurations to reproduce the issue.
  2. Simple — Reproduce the problem scenario with minimal code and components, without complex dependencies.
  3. Stable Reproduction — having a clear reproduction path.

Specific Operations:

How to ensure example completeness?​

  1. For problem scenarios that do not depend on data sources, when creating an example, retain only the necessary code to reproduce the issue.
  • Implementation of variable binding
  • Code content in the code editor (lifecycle methods, custom methods)
  • Configuration in the right-side properties panel
  • Style authoring
  1. For problem scenarios dependent on data sources, after creating an example, you can further verify the following content and provide it to the product and R&D team.
  • Data structure of the data source
  • Data version of the data source: production/preview
  • Scenario types of data sources: custom connectors/data models
  • Usage scenarios of data sources: Form Container/Data Container/Create/Edit, etc.
  • Step descriptions for data source-related operations

How to ensure the example is sufficiently small?​

  1. When you can accurately identify the problem, create a custom application/model application and drag the problematic component into it. Provide minimal code implementation. For example, in scenarios involving variable binding, only set the variables necessary to reproduce the issue in that scenario.
  2. When you cannot accurately pinpoint the root cause of the issue, you can use the process of elimination. Create a new custom application/model application, then gradually remove components and code implementations until the issue disappears. Finally, add back the last change to determine the minimal scenario to reproduce the issue.

How to ensure the issue is consistently reproducible?​

  1. Eliminate other interfering factors unrelated to the issue. You can refer to the Component Documentation to self-check the usage methods and scenarios of components, and eliminate issues caused by non-platform factors such as spelling errors in code implementation, style authoring, and custom component implementations.
  2. Narrow down the scope of the issue. If you can provide a clear reproduction path, please supplement with additional details. For example, specify whether the issue occurs only on the Mini Program side, only after the application is published, or only within the editor.

How to troubleshoot style issues​

The WeDa platform provides a rich set of basic components and offers multiple methods such as Theme, Global CSS Variables, Component-level CSS Variables, and Style API to meet style customization needs. When encountering issues while modifying styles, you can refer to the following methods for self-resolution.

Troubleshooting CSS style issues typically involves multiple aspects, including code inspection, utilizing browser developer tools, and analyzing style specificity. Below are fundamental steps and techniques to help you effectively identify and resolve CSS style problems:

Basic Steps for Troubleshooting CSS Style Issues​

  1. Identify the post-release runtime platform:
  • For h5 side/pc side style issues, you can directly inspect them using browser developer tools.
  • For Mini Program side style issues, you can launch the Mini Program WeChat IDE Preview for inspection. image

  1. Check the code: Ensure the CSS code has no syntax errors, such as missing semicolons or brackets, and verify whether property values comply with specifications. image

  2. Use browser developer tools: Utilize browser developer tools (such as Chrome DevTools) to check whether web-side styles are correctly applied. In the "Elements" panel, you can view and edit CSS styles of elements, as well as inspect network requests and responses to ensure stylesheet files are properly loaded. For Mini Program side styles, you can launch the Mini Program IDE and inspect them in WeChat Developer Tools.

  • Open Developer Tools: In Chrome, you can open Developer Tools by pressing F12 or right-clicking on a page element and selecting "Inspect".

  • Elements Panel: In the "Elements" panel, you can view and edit CSS styles of elements, as well as inspect the box model and layout.

    image

    By viewing the box model of elements, many issues can be resolved, such as "why the component is missing". Simply check whether the width, height, and display properties of the element meet expectations.

  1. Analyze style specificity: Understand selectors, CSS cascade rules, and specificity to ensure your styles aren't overridden by higher-priority rules. For example, inline styles, ID selectors, class selectors, etc. have different specificity levels. image
  2. Resolve style conflicts: If style conflicts occur, try to resolve them by refining selectors or increasing style specificity. For details, refer to the Style API documentation.
  • Use more specific rules. Add one or more elements before your selected element to make the selector more specific and gain higher priority.
<div id="test" class="box">
  <span class="text">Text</span>
</div>
.box#test .text {
  color: green;
}
.box .text {
  color: blue;
}
.text {
  color: red;
}

Regardless of the order of css statements, the text will be green because this rule is the most specific and has the highest priority. (Similarly, regardless of statement order, the blue rule will override the red rule)

Recommendations for Improving Application Maintainability​

  • Application Theme: The WeDa Editor provides multiple sets of Application Themes. Using application themes allows predefining styles for page elements, enabling different themes to change the appearance of default text, backgrounds, buttons, icons, etc. It is recommended to prioritize using themes for customizing your scenario requirements.
  • Global Styles: It is recommended to centrally write and uniformly manage modifications to global styles in the code editor.
  • Local Styles: For modifications to local styles, refer to the Component Style Practice Guide.
  • Refine Selectors: As applications are published to multiple platforms and subject to mini program style priority rules, it is recommended to specify the root element of the terminal. image