Exporting FormatStyle structs #470
Conversation
| @@ -1,4 +1,4 @@ | |||
| module github.com/360EntSecGroup-Skylar/excelize/v2 | |||
There was a problem hiding this comment.
When you are developing locally with go modules you can use replace to change where the code is pulled from to test your local changes instead of renaming the module.
styles.go
Outdated
| @@ -1885,13 +1885,9 @@ func parseFormatStyleSet(style string) (*formatStyle, error) { | |||
| // | |||
| // Cell Sheet1!A6 in the Excel Application: martes, 04 de Julio de 2017 | |||
| // | |||
| func (f *File) NewStyle(style string) (int, error) { | |||
| func (f *File) NewStyle(fs *FormatStyle) (int, error) { | |||
There was a problem hiding this comment.
I think you should add a new function that takes the newly exposed style struct instead of changing the signature of NewStyle.
As it stands, we would have to release v3 of the library since you are making a breaking change to how people would consume it. If you add a new function to take the struct like NewStyleStruct or AddStyle (or something...) then this can go out as v2.1.0.
All the private functions you changed seem fine since consumers can't see those.
|
You could use iota to give names to the numbers used in border styles and such which would further help users consume this. |
|
Reverted to something api compatible. As for iota, I will leave that alone for now. |
|
Is it possible to get this approved? I am running into performance issues, but my code is based on the templates being passed objects rather than strings. |
xuri
added
the
size/L
|
I exported Style structs to allow create the style for cells by given JSON or structure. |
…r cells by given JSON or structure
PR Details
Description
Exporting FormatStyles.
Motivation and Context
Much friendlier for any user of the library.
How Has This Been Tested
Using existing tests.
Types of changes
Checklist