You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Learn how to share and reuse entire FlutterFlow projects using libraries.
7
-
sidebar_position: 6
6
+
description: Learn how to share and reuse entire FlutterFlow projects suing libraries.
7
+
sidebar_position: 4
8
8
---
9
9
import Tabs from '@theme/Tabs';
10
10
import TabItem from '@theme/TabItem';
11
11
12
12
# Libraries
13
13
14
-
In FlutterFlow, a project can either be used to create an App or used to create a Library. A library allows you to share and reuse resources created in FlutterFlow across multiple projects. More specifically, with libraries, you can publish components, API calls, custom code, and more - all with version control. By using libraries, development becomes more efficient and scalable.
14
+
Libraries enables you to share and reuse entire FlutterFlow projects as dependencies across multiple projects. This allows teams and developers to modularize their apps by creating shared libraries that include components, API calls, custom code, and more. By using libraries, development becomes more efficient and scalable.
15
15
16
-
Imagine you're building an e-commerce app, and different teams are working on various features. One team develops a complex payment system. By using libraries, they can publish the payment system as a reusable library and allow other teams to easily import and integrate it into multiple projects without duplicating development efforts.
17
-
18
-
19
-
20
-
:::tip[possible usecases]
16
+
:::info
17
+
A **Dependency** refers to an external library or resource that your project relies on to function correctly. When you create a new FlutterFlow project, certain dependencies are automatically added to support the generated code. Also, when you use a [Custom Widget](../../ff-concepts/adding-customization/custom-widgets.md), you are essentially adding dependencies to your project. Libraries take this concept further by allowing you to add entire FlutterFlow projects as dependencies.
18
+
:::
21
19
22
-
-**Modular Development**: Build large-scale apps by separating them into smaller, independently managed projects (e.g., UI library, backend integrations, etc.).
23
-
-**Team Collaboration**: Share reusable UI components, custom functions, or API integrations across multiple apps
24
-
-**Community Sharing**: Publish libraries that can be imported and reused by the broader FlutterFlow community - like UI Kits or utility functions.
20
+
Imagine you're building an e-commerce app, and different teams are working on various features. One team develops a complex payment system. By using the Libraries, they can publish the payment system as a reusable library and allow other teams to easily import and integrate it into multiple projects without duplicating development efforts.
25
21
26
-
:::
22
+
27
23
28
-
### What’s Included When Importing a Library
24
+
### Importance of Libraries
29
25
30
-
When you import a library into a FlutterFlow project, the following resources are accessible for use:
26
+
Previously, FlutterFlow offered several methods to share resources between projects, such as team code libraries, design systems, API libraries, and by leveraging marketplace items. However, these methods had limitations, including the inability to share custom data types or custom functions alongside components or API calls and the absence of version control.
-[Custom Functions](../ff-concepts/adding-customization/custom-functions.md), [Actions](../resources/control-flow/functions/action-flow-editor.md), and [Widgets](../resources/ui/widgets/intro-widgets.md)
39
-
-[Assets](../resources/projects/settings/general-settings.md#app-assets) (Note: These are not versioned)
28
+
With Libraries, you can publish the complete FlutterFlow project as a library and import it as a dependency into other projects.
40
29
41
-
:::note
30
+
:::tip[possible usecases]
42
31
43
-
Pages and Firestore Collections are still being worked on and may come in future updates.
32
+
-**Modular Development**: Build large-scale apps by separating them into smaller, independently managed projects (e.g., UI library, backend integrations, etc.).
33
+
-**Team Collaboration**: Share reusable UI components, custom functions, or API integrations across multiple apps within a team.
34
+
-**Community Sharing**: Publish libraries that can be imported and reused by the broader FlutterFlow community.
44
35
45
36
:::
46
37
47
38
## Publishing a Library
48
39
49
-
To publish a project as a library, start by creating a FlutterFlow project as you normally would. Next, go to the **Publish as a Library** page in **App Settings**. Here you can specify the version number and message for the version you are publishing.
40
+
To publish a FlutterFlow project as a library, start by creating a FlutterFlow project as you normally would, then follow these steps:
50
41
51
42
<div style={{
52
43
position: 'relative',
@@ -55,7 +46,7 @@ To publish a project as a library, start by creating a FlutterFlow project as yo
@@ -77,13 +68,11 @@ To publish a project as a library, start by creating a FlutterFlow project as yo
77
68
:::info
78
69
- You can only publish libraries if you have access to branching, which is available to Pro+ users.
79
70
- Libraries can only be published from the main branch, and each published version is linked to a specific commit, ensuring robust version control.
80
-
- You must commit your changes before publishing a new version of the library.
81
-
- It's recommended to include a message that tells users what has changed in the version your are publishing.
82
71
:::
83
72
84
73
## Importing a Library
85
74
86
-
To import a library project into another FlutterFlow project, you must go to the **Project Dependencies** page in **App Settings**. Here you can specify the library project and version you are importing.
75
+
Open the FlutterFlow project where you'd like to import a library, then follow these steps:
87
76
88
77
<div style={{
89
78
position: 'relative',
@@ -92,7 +81,7 @@ To import a library project into another FlutterFlow project, you must go to the
@@ -112,80 +101,120 @@ To import a library project into another FlutterFlow project, you must go to the
112
101
<p></p>
113
102
114
103
:::info
104
+
You can only select a library if you have been added as a collaborator in that library project. To use a library, you must have one of these roles in the library project: Owner, Manager, Editor, or Read-Only.
105
+
:::
115
106
116
-
- You can only select a library if you have at least read access on the library project.
117
-
- For a library project to show in the drop down, you must be added as a collaborator on the project and the library project must have a published version.
118
-
- You can import publicly accessible libraries by specifying the project ID in the text field when adding a library dependency.
119
-
- By default, the latest published version of the library is imported, but you can choose to depend on an earlier version if needed.
120
-
- You can also import the `current` version of the library to use the latest state of the library on the main branch - however, this is not recommended.
121
-
- You must have a paid plan to import a library.
122
107
123
-
:::
108
+
### Dependency Conflicts
109
+
110
+
A **Dependency Conflict** occurs when two or more libraries added by a project depend on different versions of the same dependency. This creates a situation where the project cannot resolve which version to use, leading to a project error.
Let's say you are building an eCommerce app that uses multiple libraries for different purposes:
115
+
116
+
-**User Auth Library** is used for handling user authentication.
117
+
-**Payment Gateway Library** is used for managing the payment gateway.
118
+
119
+
Both library projects depend on a common library called **Components Library** but imports different versions respectively:
120
+
121
+
-**User Auth Library** depends on `Components Library v1.5.0`.
122
+
-**Payment Gateway Library** depends on `Components Library v2.0.0`.
123
+
124
+
In this scenario, the eCommerce project will detect the dependency conflict because it can't add both `v1.5.0` and `v2.0.0` of the Components Library at the same time.
125
+
126
+
#### Fixing Dependency Conflicts
125
127
126
-
You can easily upgrade to newer versions of the libraries as they become available. If a new update causes issues with your existing implementation, you also have the option to revert to a previous version.
128
+
Follow these steps to ensure both libraries rely on the same version of Components Library:
127
129
128
-
130
+
1.**Upgrade both libraries**: If updates are available, start by upgrading both the User Auth Library and Payment Gateway Library to their latest versions. Often, newer versions of libraries are designed to use the latest version of the Components Library, which can help resolve conflicts.
131
+
2.**Modify Libraries**: If you have access to the library projects, adjust the dependencies of either User Auth Library or Payment Gateway Library (or both) to use the same version of the Components Library.
132
+
3.**Contact Library Maintainers**: If you do not own the library yourself, reach out to the maintainers of the library projects. They may provide guidance, suggest workarounds, or release a version that addresses the conflict.
129
133
130
134
## Access Library Resources
131
135
132
-
Once the library is imported, components and resources are accessible within the project. It's important to note that these resources show up where they are instantiated. For example:
136
+
Once the library is imported, following resources are accessible for use:
-[Custom Functions](../../ff-concepts/adding-customization/custom-functions.md), [Actions](../../resources/control-flow/functions/action-flow-editor.md), and [Widgets](../../resources/ui/widgets/intro-widgets.md)
145
+
-[Assets](../../resources/projects/settings/general-settings.md#app-assets) (Note: These are not versioned)
146
+
147
+
:::note
148
+
Pages are still being worked on and may come in future updates.
149
+
:::
150
+
151
+
It's important to note that these resources show up where they are instantiated. For example:
133
152
134
153
-**Components** appear in the widget palette.
135
154
-**API calls** appear when making API calls in the action flow editor.
136
-
-**App State variables** appear where you can update app state in an action or leverage app state in a widget property.
137
155
-**Custom functions** are available when setting up actions or functions within the app.
138
156
139
157
This ensures that only relevant resources are shown where they are needed, optimizing performance and discoverability.
Library versioning allows you to manage different versions of a library project over time. Using versioning, library users can control which version of a library to use in a project, ensuring compatibility and reducing the risk of breaking changes.
143
163
144
-
### Manage Dependency Conflict while Import
164
+
:::info[Importance of Library Versioning]
165
+
-**Maintain Backward Compatibility**: It ensures older versions of the library continue to work as expected while introducing new features.
166
+
-**Roll Back Changes**: In case of bugs or issues in a new version, you can easily revert to a previous stable version.
167
+
-**Control Updates**: Library users can decide when to upgrade to the latest version, rather than being forced into changes.
168
+
:::
145
169
146
-
A **Dependency Conflict** occurs when two or more libraries added by a project depend on different versions of the same dependency. This creates a situation where the project cannot resolve which version to use, leading to a project error.
When you're ready to update your library, ensure that all modifications are committed to the main branch of the library project and then publish as per instructions [here](#publishing-a-library).
149
173
150
-
Let's say you are building an eCommerce app that uses multiple libraries for different purposes:
174
+
:::tip
151
175
152
-
-**User Auth Library** is used for handling user authentication.
153
-
-**Payment Gateway Library** is used for managing the payment gateway.
176
+
-While publishing a new version, add a description to highlight what's new or changed in this version.
177
+
-Each time a new version is published, the version number will automatically increment.
154
178
155
-
Both library projects depend on a common library called **Components Library** but imports different versions respectively:
179
+
:::
156
180
157
-
-**User Auth Library** depends on `Components Library v1.5.0`.
158
-
-**Payment Gateway Library** depends on `Components Library v2.0.0`.
181
+
### Import Specific Version
159
182
160
-
In this scenario, the eCommerce project will detect the dependency conflict because it can't add both `v1.5.0` and `v2.0.0` of the Components Library at the same time.
183
+
When importing a library into a project, you have the flexibility to choose which version of the library to use. By default, the latest version will be selected.
Follow these steps to ensure both libraries rely on the same version of Components Library:
187
+
### Update to Latest Version
165
188
166
-
1.**Upgrade both libraries**: If updates are available, start by upgrading both the User Auth Library and Payment Gateway Library to their latest versions. Often, newer versions of libraries are designed to use the latest version of the Components Library, which can help resolve conflicts.
167
-
2.**Modify Libraries**: If you have access to the library projects, adjust the dependencies of either User Auth Library or Payment Gateway Library (or both) to use the same version of the Components Library.
168
-
3.**Contact Library Maintainers**: If you do not own the library yourself, reach out to the maintainers of the library projects. They may provide guidance, suggest workarounds, or release a version that addresses the conflict.
189
+
You can easily upgrade to newer versions of the libraries as they become available.
190
+
191
+
:::tip
192
+
193
+
- If a new update causes issues with your existing implementation, you also have the option to revert to a previous version.
194
+
- Always test your app after upgrading to ensure that the new library version works well with your existing project.
195
+
196
+
:::
169
197
198
+
170
199
171
200
## FAQs
172
201
173
202
<details>
174
203
<summary>What will happen to existing team libraries?</summary>
175
204
<p>
176
-
Team code and API libraries will be migrated to library Projects. These projects will be imported as a library with the latest version specified as the version. The components within team design systems will move into their own projects, while design systems will continue to exist but only containing the theme settings.
205
+
Team code and API libraries will be migrated to Library Projects. These projects will be imported as a library with the latest version specified as the version. The components within team design systems will move into their own projects, while design systems will continue to exist but only containing the theme settings.
177
206
</p>
178
207
</details>
179
208
180
209
<details>
181
-
<summary>Will libraries work with Marketplace?</summary>
210
+
<summary>Will Libraries work with Marketplace?</summary>
182
211
<p>
183
212
We plan to allow users to import a marketplace project as a library, making it easier to integrate marketplace resources into your projects.
184
213
</p>
185
214
</details>
186
215
187
216
<details>
188
-
<summary>How do libraries work with themes?</summary>
217
+
<summary>How do Libraries work with themes?</summary>
189
218
<p>
190
219
The parent project's design system takes precedence over the imported library's design system. For example, if a library uses the standard FlutterFlow color scheme, the values defined in the parent project will override those in the library. However, if the library project has a custom color that the parent project does not have, it will be used as-is in the parent project.
191
220
</p>
@@ -194,13 +223,13 @@ The parent project's design system takes precedence over the imported library's
194
223
<details>
195
224
<summary>How are API keys shared?</summary>
196
225
<p>
197
-
We're working on Library Values, which will allow users to set specific values when they import a library. This feature will be available soon.
226
+
We're planning to leverage environment variables, as part of the Development Environment features, to allow users to add their API keys to their own projects. This ensures that the API key is not shared when the project is published as a library.
198
227
</p>
199
228
</details>
200
229
201
230
<details>
202
231
<summary>How does nested dependencies work?</summary>
203
232
<p>
204
-
Projects can import libraries that themselves have imported other Libraries as dependencies. However, if the project and the library share the same dependency, the version must match exactly to avoid conflicts.
233
+
Projects can import Libraries that themselves have imported other Libraries as dependencies. However, if the project and the Library share the same dependency, the version must match exactly to avoid conflicts.
0 commit comments