It's impossible to tell upfront if the particular customization is used only once on a page or if there are multiple instances of it. Using SharePoint Framework, you build customizations that end-users add to SharePoint.
All valid CSS is also valid Sass, which is very helpful if you haven't worked with Sass before and want to gradually learn its capabilities. Sass is a superset of CSS and offers you a number of features such as variables, nesting selectors, or mixins, all of which simplify working with and managing CSS styles over the long term.įor a complete set of features, see the Sass website. In SharePoint Framework, you can use both CSS and Sass. Following is a sample structure of a React application with a number of components, each with its own CSS file. With that in mind, it makes perfect sense for you to store CSS styles for the particular component along with all other asset files next to the component. Ideally, components should be isolated and be able to be used on their own. Splitting your solution into multiple components allows you to simplify the development process and makes it easier to test and reuse the components in your solution.īecause components have presentation, they often require CSS styles. A component can be simple and define only the presentation, or it can be more complex and include state and other components. In many JavaScript libraries, these building blocks are called components.
The UI of your solutions often consists of multiple building blocks. To avoid such risks, you should define your CSS styles in such a way so that they won't affect anything else on the page other than your customization. Because it's a part of the page, unless explicitly isolated, all CSS styles present on the page apply to it, potentially resulting in an experience different from what you intended. While this removes a number of restrictions that come with the add-in model, it exposes your solution to risk. SharePoint Framework solutions are a part of the page and integrate fully with the page's DOM. In both cases, your code is not affected by other elements and styles defined on the page. Your code can be executed in an iframe as an add-in part, or as an immersive application that takes control of the whole page. When building SharePoint customizations using the add-in model, the solution is isolated from other elements on the page.
SharePoint Framework customizations are part of the page This article describes how you can make the best use of the capabilities provided with the SharePoint Framework and build your CSS styles in a robust way. When building SharePoint Framework solutions, you can use CSS to define how your customization should look and behave.
0 kommentar(er)
